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Foreword 


(This  foreword  is  not  part  of  American  National  Standard  Z39. 50-1988.) 
This  standard  was  prepared  by  Standards  Committee  D,  "Computer-to-Computer Pro- 
tocols "  of  NISO  the  National  Information  Standards  Organisation  (Z39).  Standards  Com- 
mitted D  was  organized  to  develop  protocols  at  the  application  layer  of  the  Open  Systems 
Interconnection  (OSI)  Reference  Model  (ISO  7498)  of  the  Internafconal  Organization  for 
Standardization  (ISO).  Applications  to  be  considered- include  information  retrieval  inter- 
library  loan,  and  the  transfer  of  bibliographic  and  other  types  of  database  records.  The 
committee  has  monitored  the  development  by  other  standards  bodies  of  related  application 
protocols,  including  file  transfer  and  message  transfer. 

This  standard  responds  to  a  need  for  a  protocol  to  exchange  messages  between  two 
computers  for  the  purpose  of  information  retrieval:  to  enable  a  requesting  computer  to  1) 
request  that  the  responding  computer  search  a  specified  database.and  identify  records  which 
meet  specified  criteria,  and  2)  request  transmission  of,  and  receive,  some  or  all  of  the 

identified  records.  .  .         , 

The  requesting  and  responding  computers  are  referred  to  respectively  as  the  origin  and 
target  It  is  assumed  that  the  origin  initiates  requests  on  behalf  of  a  user  who  wishes  to  search 
a  database  located  on  the  target  system.  This  standard  addresses  the  protocol  between  the 
corresponding  information  retrieval  applications  on  the  origin  and  target  systems;  it  does 
not  address  the  interaction  between  the  origin  computer  and  the  user.  ^ 

The  protocol  provides  the  following  basic  capabilities.  Upon  establishment  of  an  infor- 
mation retrieval"  session  (session  establishment  is  outside  the  scope  of  this  standard),  the 
origin  may  submit  a  Search  request  which  includes  a  query  (discussed  below)  and  param- 
eters which  determine  whether  or  not  the  records  resulting  from  the  search  are  to  be  re- 
turned as  part  of  the  response.  The  target  responds  with  a  count  of  the  records  identified  and 
..  possibly  some  orall  of  the  records.The  origin.may.then  submit  a  Present  request,  requesting., 
transmission  of  any  number  of  the  records.  The  origin  assumes  that  the  records  selected  by 
the  search  request  form  an  ordered  set  which  may  be  referenced  by  sequential  position 
within  the  set  The  ordering  of  the  records  is  determined,  by  the  target  system.  The  origin 
may  request  (for  example)  records  one  through  four/  and  follow -with  a  request  forrecords 
four  through  eight,  and  then  records  two  through  three,  etc.  The  origin  may  submit  as  many 
such  Present  requests  as  desired,  and  may  then  submit  another  Search  request. 
Optional  capabilities  include  the  following: 

(1)  The  origin' may  specify  an  element  set  name  specifying  the  data  ele- 
ments that  should  be  transmitted  in  cases  where  the  origin  does  not 
wish  to  receive  full  database  records. 

(2)  The  origin  may  name .2,  result  set  so  that  it  may- be  subsequently 
referenced  by  name. 

(3)  The  origin  may  delete  a  previously  named  result  set. 

(4)  The  target  may  impose  access  control  restrictions  on  the  origin,  by 
demanding  authentication  before  processing  a  request: 

(5)' The  target  may  provide  resource  control  by  sending  an  unsolicited 
status  report  during  processing  of  an  operation,  and  allowing  the 
origin  to  decide  whether  the  operation  should  continue. 


t   ' 


[31 


!    1' 


Aside  from  the  basic  and  optional  capabilities  of  the  protocol,  the  query  formulation 
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•  .  ^'.derations  for  the  committee.  Various  information  retrieval  systems 
KEL^^SS  m  committee  established  the  following  Splines: 

1    Oueries  are  transmitted  according  to  a  common  format   Thus  the 
origTnts  not  responsible  for  translating  its  query  structure  to  that  of  the 
Z    t  icause  Siat  would  require  distinct  translation  capabih i^ o 
each  system  accessed.  Instead,  the  origin  translates  to,  and  the  target 

•  SHSueatiy  named  and  added  to  the  standard.  Each  search 

SquSt  species  the  name  of  the  format  of  the  query  it  contains. 
3.  A  mechanism  is  provided  to  allow  two  systems  to  use  a  pnvate,  mutu-. 
ally  agreed  upon  query  format. 

terms  (or  phrases)  ^1      '    T^hlStisMnl^,  to  position  withia  a  record, 
The  Information  R«nevai  P  £  ^  ^^  the  response  messages  from 

~"3£EL.  dishes  ,«o  types  -^^-^SSl  S^ 
ords)  that  can  apr™^ ' ^ ?<St£ pS  "ihe  smndard),:provides  a 
defining  other  record  types.  Appends .  u  P»m  P  structure 

the  ^ET^ISS-  reonimd.  Some  issnes  tha,  might  be  considered  m  the  future 

are:  .  ...  

.    List  Databases-,  to  obtain  a  iis"t  of  the  "names-of  databases  available  to 

.    S^sfpo^^Sn  a  list  of  access  points  to  records  in  spec- 

.  Brt^o"  obtain  a  list  of  access  point  values  preceding  and  following  a 

•"  snecified  access  value,  or  meeting  other  criteria 

.  Sort  Result  Set:  to  request  that  a  result  set  be  sorted  in  a  specified  order 

.  Save  Result  Set:  to  save  and  recall  a  result  set  across  association 

.  List  Element,:  to  obtain  a  listing  of  the  data  elements  contained  in  the 

rpmrds  of  the  specified  database 

.  Denne  Elernem  Set:  to  define  and  name  a  set  of  element,  (a  subset  of 
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Handling  Services  ^  lni,.resp0„se  APDUs  to  the 

.    Embedding  of  Int.  to  map  i  A.associate  service 

common  applica.ton  a* «'*™  £?'£  standardte  .tribute  lists  tor 

•  ^SXstrrerd^at,  resource  report  formats,  and 
additional  query  types  database  concurrency  control 

•  SEES  STS-^CS  an  origin  system  to  spec,,  con- 
currency  control  options.  ^ 
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1.  Introducii' >:• 

.  This  is  c  •  •  ;'. 
systems.  It  is  '," "  '■■ 
connection  ('*>'" 
tion  is  to  a!'---  v 
agreement  c ';::•.'■-' 
This  st.-r-.iar 
and  is  cone:  r  i v.;  .1 
databases. 

i.i  Scope  r.!-.a  i 
application  «•■!'.•. 
(section  4),  f  <r ' 
The  In .".- r; ■ 
provide  c'ap'viii'. 
the  implern:.  !'•'■•  • 
define  the  f-.' ".c  • 

'The'prr.:.-: 
■  the  rules  for  .cxt ; 
implements';  .-.• 
This  Sir'*. 
sciences..  It..!;'. 
telecommunK..i; 
via  other  p'  ;  :'i- 

1.2  Mode!     •*  = 

database  ur:.'-  " 

standards  r.:v.  - 

specified  ii;  ;'<■-' 

ably;'differc":. 

by  which  U  ■'■ 

databases,  !•"  '• 

systems  to  -.  •' 

Thet«  ."" 

each  with  :.  '■■ 


iil 


xii 


■■■ 


;r$Ki 


i;  ■•■■*'! 


& 


Information  Retrieval  Service  and  Protocol 


ANSI/NISO 
Z39. 50-1988 


American  National  Standard  for 

Information  Retrieval  Service 

Definition  and  Protocol  Specification 

for  Library  Applications 


i   ! 


1.  Introduction 

^-   •  r,  .m  «r  standards  produced  to  facilitate  the  interconnection  of  computer 

and  b  conctnSln parted."  with  the  retrieval  of  information  stored  m  maemoe  readable 
databases. 

1  1  Scone  and  Field  of  Application.  This  standard  describes  the  Information  Retrieval 
appSon'rvfce  (section'')  and  specifies  the  Information. Retrieval  apphcaUon  protocol 

"^formS n^^S^Vice  is  described  in  terms  of  services  that 

The  Int?r™«°"  *e  y, ■  deScription.  neither  specifies  nor  constrains  . 

jnSS^n^^S^  system.  The  purpose  of  the  service  description  is  to 

^ t^^o^^^ol  ofSie  protocol  contr.i^tio, 
the  rute  ?or  exchanging  this  information,  and  the  conformance  requirements  to  be  met  by 

lmP ITsU^Is  ^ndTUcularly  for'  use  in  the  area  of  library  and  information 
science  J?S^  ^ncction^riented,  program-to-program,communiCation  uti  izing 
SLommuntuons.  It  does  not  address  the  interchange  of  information  with  terminals  or 
via  other  physical  media. 

I  2  Model.  The  objective  of  this  standard  is  to  facilitate  the  open  interconnection i  of 
databasTu  ers  with  database  provider,.  It-is  necessary  to  .distinguish  between  the  set  of  OS 
stanSaSs  and  me  hardware  and  software  implementation  of  a  system  using  the  protocols 
standards  and  the  ham  databases  ^  implemented  dlfFer  consider. 

IbTy^dfff e  t  sys  t^cILJ^s  for  describing  the  storage  of  data  and  the  means 
by^hilit  c- be  accessed.  A  common,  abstract  model  is  ^"^^^S 
databases,  to  which  an  individual  system  can  map  its  .mplementation.  Tins  enables  different 
systems  to  communicate  in  standard,  mutually  understandable  terms. 
"  The  te  m  "database"  as  used  in  this  standard  refers  to  a  collection  of  one  or  more TUes 
each  with  a  unique  name.  A  group  of  files  within  a  database  may  also  have  a  name  and  be 
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_ed  as  a  single  Tba,:  ^«£Z^^^^<» 
record.  AU  of  the  records  withm  a  given  ^ha  c  An  acccss  point  is  a  unique  or  non- 

of  data  elements  and  a  common  set  o  access^ p       .  ^  othcr  acccss  points  in  a 

unique  key  that  can  be  sP^ed  «« her  *  ^  lQ  a  data  elemeQt,  be  denved  from  a 

search  for  records.  Mi  ««»  P01^ ^Lt  of  two  or  more  data  elements 
data  dement,  or  be  the  combination  of  aU  o  pan    ^^      ^ues  lo  ^  matched  against 
**  * .carcUuerV  ^  be  appUedtc ,a b^^^m^  by  applying  the  search  query 
^^S^t^^^^^f  be  referenced  in  a  subsequent  search  query 

statement  and  manipulated  to  ^ a  ^^g  docs  not  necessarily  require  phytol 
For  generality,  it »  assumed  ^q^ery  P-  ess    g  ^  ^  g<>  ^ to 

access  to  records;  a  result  set  is  thus  as mm  u  ^  assumed  that 

records,  as  opposed  to  the  actual  **^™£^  control,  which  would  prevent 
the  database  records  are  locked.  Metho  ds f™*™^  b   this  standard.)  A  result  set 

access  point  'author'  contains  the  value  'longfellow. 

•   n  ^f*  Wcti  the  set  of  items  with  the  specified  properties  (the 
Following  the  processing  of  a  search ,the set °"  £?  for  subsequent 

result  set)  is  made  available  by  the  te^.fSiV  s  that  S  a  Lmed,  ordered  .list  of 

retrieval  requests.  The  logical  ^^°^^^^  position  of  the  triple  in  the 

triples  consisting  of  (a)  an  ordinal  — ^^  ^  significance  only)  within 

that  is,  by  (a). 


1.3  References 
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Systems-Open  Systems  Interconnection-Service  Defi- 
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2.  Definitions 

document. 

ADPU—Scc  Application  Protocol  Data  Unit. 

a  ^nrvrative  relationship  between  two  application-entities, 

presentation-services. 

p«r  thP  Information  Retrieval  service  and  protocol,  an  application  asso- 
dadon  stnaCus  to  an- individual  communication  session  between  a 
datbie  u"r  ancl  a  database  provider.  Each  association  consrsts  of  an  . 
oSnTppStion  and  a  target  application,  and  these  roles  may  not  be 
reversed  within  an  association.  .      •  •  - 

•    Application  Entity-^  aspects  of  an  application  process  pertinent  to  Open  Systems  Inter- 
connection. 

tions.  ,"  _,i 

'      "  The  rules  governing  the  format.and  exchange  of  mformatiou.between  an 

origin  and  target  application. 
Application  Protocol  Control  Information-ln^ra^on  exchanged  between  applications, 
using  a  presentation  connection,  to  coordinate  that  joint  operation. 

The  information  conveyed  by  application  protocol  data,units. 

Application  Protocol  Data  Unit-A  unit  of  information  specified  in  an  application  protocol 
and  consisting  of  application  protocol  control  information. 


A  unit  of  data  passed  between  an  origin  and  a  target. 


Application  Service  User-Tb*  portion  of  an  application  which  makes  requests  upon  the 
Open  Systems  Environment.  •    • 

(The  concept  of  service-user  is  employed  to  facilitate  the  specification  of 
protocol  procedures  and  is  not  analogous  to  the  database  user.) 

explicitly  terminated. 
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Database  Provider-^o  application  that  provides  access  to  a  database  local  to  that  applica- 

tion. 

Database  User-Tho  application  that  accesses  a  remote  database. 

Name-A  linguistic  construct,  expressed  in  some  language^  which  corresponds  to  an  object 
!I  denoL  Cue.,  identifies)  the  object  to  wh.ch  it  is  bound. 

Origin  Application-^  application  that  initiates  an  association  and  is  the  source  of  re- 
quests  during  the  association. 

The  database  user. 

OSI— Open  Systems  Interconnection. 

Prirnitlve-An  abstract  element  of  interaction  between  service-user  and  service-provider. 

p     ,/,  <:*     An  ordered  list  of  triples  consisting  of  (a)  an  ordinal  number  corresponding  to 
Result  5f'-Aor^  iQ  he  list!  (b)  a  database  name,  and  (c)  a  unique  record  identifier  (of 

SmcS 
search  query. 

Service  Provider-Th,  provider  of  communication  service  between  two  service  users: 

(The  concept  of  service-provider  is  employed  to  facilitate  the  sp^tioji 

of  protocol  procedures.  Itis  not  analogous  to  the  database  provider,  and  it  -  - ,    .-    • 

does  not  refer  to  providers  of  telecommunication  services.) 

'i . 

Target  Applicatlon-Tte  application  that  accepts  an  association  and  is  the  sink  for  requests, 
during  the  association. 

The  database  provider. 

Primitive  Name-A  kind  of  name,  the  internal  structure  of  which  is  not  required*  be 
understood  or  have  significance  to  users  of  the  name. 


cither  oris.'.'"  ■  = 

event. 

The '•■■'.•  • 

cannot  be  •' - 
The  C' -.•... 

control  sc;. ;. 
tion  servi  .•: . 
phases  du  :••'•,' 

.  terminati-  '.'•. 
required  ii'.n" 
application  :•■ 
during  th.-  .;• 
services  for  :. 

3.2  FaciHsu 
standard.  A; 
consists  r.  i- 
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3.  Information  Retrieval  Service 

This  section  defines  the  Information  Retrieval  service,  which  is  supported  by  the  Infor- 
mation  Retrieval  protocol. 

2 TJZ£Z I'^pUda,  established  by  the  origin  and  mny  be  expheuly  teennnnted  by 
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either  origin  or  target,  or  implicitly  terminated  by  a  communication  failure  or  other  external 

event  *•  .    . 

The  roles  of  origin  and  target  may  not  be  reversed  within  an  association.  An  association 
cannot  be  restarted;  thus  no  status  information  is  retained  once  an  association  ts  released. 

The  complete  application  service  is  composed  of  the  common  application  association 
control  service  which  provides  association  management,  and  one  or  more-specific  applica- 
tion services  such  as  the  Information  Retrieval  application  service.  There  are  three  distinct 
phases  during  the  life  of  an  application  association:  establishment,  information  transfer,  and 
termination.  The  common  application  association  control  service  provides  all  of  the  services 
required  during  the  establishment  and  termination  phases,  including  the  selection  of  an 
application  context  specifying,  among  other  things,  the  set  of  service  elements  that  are  valid 
during  the  information  transfer  phase.  Section  4.2.1.2  specifies  those  common  application 
services  for  association  control  that  are  assumed  by  the. Information  Retrieval  service. 

3  2  Facilities  of  the  Information  Retrieval  Service.  There  are  seven  facilities  defined  by  this 
standard.  All  consist  of  a  single  service  element,  except  the  Termination  facility,  which 
consists  of  two  service  elements. 


(1)  Initialization  Facility 

Init  Service  Element:  Init  request  from  the  origin  followed  (possibly 
after  one  or  more  intervening  Access-control  and/or  Resource-con- 
trol request/response  sequences)  by  an  Init  response  from  the  target. 

(2)  Search  Facility  "  _  .  ' 
Search  Service  Element:  Search  request  from  the  origin  followed  (pos- 
sibly after  one  or  more  intervening  Access-control  and/or  Resource- 
control  request/response  sequences)  by  a  Search  response'from  the 

target 

(3)  Retrieval  Facility  .'' 

Present  Service  Element:  Present  request  from  the-  origin  followed 
(possibly  after  one  or  more  intervening  Access-control  and/or  Re- 
source-control request/response  sequences)  by  a  Present  response 
from  the  target. 

(4)  Result-Set-Delete  Facility 

Delete  Service  Element:  Delete  request  from  the  origin  followed  (pos- 
sibly after  one  or  more  intervening  Access-control  and/or  Resource- 
control  request/response  sequences)  by  a  Delete  response  from  the 

target. 

(5)  Access  Control  Facility 

Access-Control  Service  Element:  Access-control  request  by  the  target, 
following  an  Init,  Search,  Present,  or  Delete  request  by  the  origin,  or 
following  a  Resource-control  or  Access-control  request/response  se- 
quence, and  followed  by  an  Access-control  response  from  the  origin. 

(6)  Accounting/Resource  Control  Facility      . 

Resource-Control  Service  Element:  Resource-control  request  by  the 
target,  following  an  Init,  Search,  Present,  or  Delete  request  by  the 
origin,  or  following  a  Resource-control  or  Access-control  request/ 
response  sequence,  and  followed  by  a  Resource-control  response 
from  the  origin. 


••  • 
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(1\  Termination  Facility  . 

The  Termination  Facility  allows  an  origin  or  target  system  to  initiate 
abrupt  termination  of  the  association,  or  an  origin  system  to  initiate 
graceful  termination. 

IR-Abort  Service  Element:  IR-abort  request  by  either  the  origin  or 
the  target. 

IR-Release  Service  Element:  IR-Release  request  by  the  origin  fol- 
lowed by  an  IR-Release  response  by  the  target. 

The  IR-Abort  and  IR-Release  services  map  directly  onto  the  A- 
ABORT  and  A-RELEASE  services  (respectively)  of  the  common  ap- 
plication association  control  services. 

3.2.1  Initialization  Facility 

i  7  t  I  Ink  Service  Element.  The  Init  service  element  allows  an  origin  to  propose 

by  the  target  or  else  terminate  communication. 

3  2  111  ID/Authentication.  The  origin  and  target  agree,  outside  the  scope  of  the 
.t.ndafd  whether  or  n0t  this  parameter  is  to  be  supplied  by  the  origin,  and  if  so,  what  the 
T^T^Z*  used  by  {he  target  to  determine  if  the  origin  is  authorized  to  enter  into 
communication  with  the  target  -  ,  '  -~ 

,,,n  ootions.  The  Init  request  specifies  either  "will  use"  or  "will  not  use/!  and 
thelni?^^ 

1.  search 

2.  present 

3.  delete. 

If  the  request  specifies  "will  not  use"  for  a  particular  capability,  then  the  origin  should  Ignore 
the  value  in  the  response  for  that  capability. 

Table  1 
Parameters  of  the  Init  Service  Element 


PARAMETER 


ORIGIN 
REQUEST 


TARGET 
RESPONSE 


ID/Authentication 

Options 

Preferred-Message-Size 

Maximum-Record-Size 

Result 
User-lnformation-Field 

Reference-ID 


x  (optional) 

x 

x 

x 

x  (optional) 
x  (optional) 


x 
x 
x 
x 


x  (optional) 
x  (if  applicable) 


Ina<:.!: 
Init  resp:-".. 


If  the  tec".  " 
"will  use"  :".! 
subject  to  c  . 


t.Tit  •'<•■ 

:k'C'T''. 
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In  addition,  the  Init  request  specifics  either  "will  support"  or  "will  not  support,"  and  the 
Init  response  specifies  "will  use"  or  "will  not  use"  for  each  of  the  following  capabilities: 

1.  resource-control 

2.  access-control.  .  .■ 

If  the  request  specifies  "will  not  support"  for  a  given  capability,  and  the  response  specifies 
"will  use"  for  that  capability,  then  the  value  of  Result  must  be  "reject"  These  capabilities  are 
subject  to  expansion  in  future  versions  of  this  protocol  and  are  defined  as  follows: 

Search— The  origin  specifies  "will  use"  for  "search"  if  it  intends  to  sub- 
mit Search  requests.  If  so,  the  target  indicates  that  it  is  willing  (or  unwill- 
ing) to  accept  Search  requests  by  specifying  "will  support"  (or  "will  not 
support")  for  "search." 

Present The  origin  specifies  "will  use"  for  "present"  if  it  intends  to 

submit  Present  requests.  If  so,  the  target  indicates  that  it  is  willing  (or 
unwilling)  to  accept  Present  requests  by  specifying  "will  support"  (or 
"will  not  support")  for  "present" 

Delete— -The  origin  specifies  "will  use"  for  "delete"  if  it  intends  to  submit 
Delete  requests.  If  so,  the  target  indicates  that  it  is  willing  (or  unwilling)  to 
accept  Delete  requests  by  specifying  "will  support"  (or  "will  not  sup- 
port") for  "delete." 

Resource-Control— The  origin  indicates  that  it  is  prepared  to  receive  and 
respond  to- a  Resource-Control  request. from  the  target,  by  specifying  ;.  ... 

"will  support"  for  "resource-control."  Conversely,  the  origin  indicates 
that  it  is  not  prepared  to  receive  a  Resource-Control  request  by  specifying    • 

"will  not  support"  In  the  latter  case,  if  the  target'cannot  suppress  sending  . 
a  Resource-Control  request,.it  should  reject-the-.connection  by  setting  -,     . 
Result  to  "reject"  specifying  "will  use"  for  "resource-control,"  and  (op-' 
ttonally)  supplying  a  text  message  in  the  User-Information-Field. 

Access-Control — Likewise,  the  origin  indicates  whether  or  not  it  is  pre-      _ 
pared  to  receive  and  respond  to  an  Access-Control  request  from  the  tar-  •    '••" 
get,  by  specifying  "will  support"  or  "will  not  support"  for  "access- 
control."         .  " 
Security  is  invoked  at  different  levels.  In  addition  to  user  authentication     ■ 
at  the  outset  of  an  association,  security  might  be  invoked  to  control  access 
to  a  particular  database,  record,-  result-set,  or  use  of  a  command. 

If  the  origin  is  not  capable  of  receiving  an  Access-Control  request,  and  if 
security  requirements  on  the  target  system  mandate  that  security  (other 
than  that  which  might  be  provided  by  the  parameter  ID/Authentication) 
be  invoked  at  the  outset  of  an  association,  then  the  target  should  reject 
the  association  by  setting  the  parameter  Result  to  "reject,"  and  specifying 
"will  use"  for  "access-control."  However,  if  the  target  invokes  security,  but 
not  at  the  association  level,  then  the  target  may  choose  to  accept  the 
connection.  In  that  case,  if  the  target  subsequently  receives  a  command 
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.hat  would  trigger  an  Access-Control  request,  the  target  agrees  to  suppress 
he  request  anTrespond  to  the  command  with  an  error  status  indicating 
that  a  security  challenge  was  required  but  could  not  be  tssued. 

3.2.1.1.3  Preferred-Message  and  ^-^^.^^ 
tains  Preferred-Message-Size  and  ^™^^£^£  The  Init  response 

-ft ^get  has  the  option  -— ^  ^^^  S^T ^ 
ablC  The  usage  of  these  parameters  is  specified  in  section  3.3. 

i!Sed!  L  origin  is  expected  to  terminate  communication. 

3  2  1  15  User-Information-F.eld.Thisfieldmaybeusedbyeithertheongmortarget 

for  additional  information,  not  specified  by  this  standard. 
3  2  1  i  6  Reference-ID.  See  section  3.4. 
\22  Search  Facility.  The  Search  facility  enables  an  origin  system  to  query  databases  at  a 
Jget  sys^m  and  to  receive  information  about  the  results  of  the  query. 

„      •     T7i  „,»„t  Thp  <>.aivh  service  element  allows  an  origin  to  send  a;  . 
3.2.2.1  Search ^^^^^Torrn:  from  the  specified  set  of  items,"  ' 
query  to  a  target  The  query  takcs.the  to uowmg  identified  is  called  the  "result 

identify  those  ^W£Z$£%£%£  retS  requests.  However,  depending 

s^^^^fllf^X  onlor  more  items  identified  by  the- result  set  may  be- 
on  the  parameters  of  the- search   one  ^  ^  ordered  ^  aems 

IZttdt  £^^  *  -  -ition  of  the — ^ the 

result  set,  beginning  with  one  (1).  (See  Table  2.) 

,17  11  Ouerv-Type,  Query,  and  Database-Names.  The  parameter  .Q»^Type 

Th^'properties  indicated"  are  specified  by  .the ^— »  ^  ^^  what  databascs 
and  that  A  and  B  may  be  searched  in  combination  (but ^  not :A  an^>  ™  ^  .Q  a 

S^tr^^  *- — »>■ 

^S;JS^SSSl'rr  eolation.  If  a  result  se,  *«,  the  same  name 


0.:; 


already  r:; !,.; 
Replace-!  r,--ii'. 


Ifarf.vcr-'i.', 

then  arc-::  :;•;' 

ignored.  Tiu-  if. 
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for  confer.-.  :<•■•' 
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Result-S"'^^ 
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Name)  r' 

Search  r" 

available 
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Table  2 
Parameters  of  (he  Search  Service  Element 


ORIGIN 

TARGET 

PARAMETER 

REQUEST 

RESPONSE 

Query-Type 

X 

Query 

X 

Database-Names 

X 

Result-Set-Name 

X 

Replace-Indicator 

X 

Element-Set-Names 

x  (optional) 

Small-Set-Upper-Bound 

X 

Large-Set-Lower-Bound 

X 

Medium-Set-Present-Number 

X 

Database/Diagnostic-Records 

x  (if  applicable) 

Result-Count 

X 

Number-of-Records-Returned 

X 

Next-Result-Set-Position 

X 

Search-Status 

X 

Result-Set-Status 

x  (if  applicable) 

Present-Status 

x  (if  applicable) 

Reference-ID 

x  (optional) 

x  (if  applicable) 

already  exists  at  the  target,  then  the  action  taken  depends  on  the  value  of  the  parameter 
Replace-Indicator,  as  follows: 

•    If  the  value  of  Replace-Indicator  is  "on,"  then  prior  to  processing  the 

query,  the  existing  result  set  whose  name  is  specified  by  the  parameter       _.-,;.'  ...- 
Result-Set-Name  will  be  deleted,  and  a  new  result  set  by  that  name 
created.  The  initial  content  of  the  result  set  is.aull. 

«  If  the  value  of  Replace-Indicator  is  "off,"  the  search  is  not  processed; 
an  error  diagnostic  is  returned  by  the  target  and  the  existing  result  set 
whose  name  is  specified  by  the  parameter  Result-Set-Name  is  left  un- 
changed. 

If  a  result  set  does  not  exist  with  the  name  specified  by  the  parameter  Result-Set-Name, 
then  a  result  set  by  that  name  is  created  by  the  target  and  the  parameter  Replace-Indicator  is 
ignored.  The  initial  content  of  the  result  set  is  null.  v  _       . 

A  target  system  need  not  support,  in  general,  the  naming  of  result  sets  by  the  origin  (see 
for  conformance  section  4.4.3,  "Statement  Requirements").  However,  the  result  set  whose 
name  is  "defoult"  must  be  supported  bythe  targetsystem.  If  the  origin  specifies  "default"  as 
Result-Set-Name,  then  the  Replace-Indicator  must  be  "on." 

A  result  set  created  by  a  Search  request  (that  is,  specified  by  the  parameter  Result-Set- 
Name)  may  be  referenced  in  a  subsequent  Present  request  or  as  an  operand  in  a  subsequent 
Search  request  (for  example,  in  a  Type-1  query).  The  result  set  named  "default"  remains 
available  for  reference  from  the  time  it  is  created  until  the  end  of  the  association  during 
which  it  is  created,  or  until  it  is  either: 


overwritten,  because  the  name  "default' 
Name  in  a  subsequent  Search  request,  or 


is  specified  as  Result-Set- 
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•  unilaterally  erased  or  deleted  by  the  target. 

Any  result  set  other  than  the  result  set  named  "default"  remains  available  for  reference 
from  the  time  it  is  created  until  it  is  deleted  in  one  of  the  following  ways: 

«    by  a  Delete  request 

•  implicitly,  because  a  result  set  was  specified  by  the  same  name  in  a 
Search  request,  and  the  value  of  the  parameter  Replace-Indicator  was 

"on" 

•  unilaterally  by  the  target  (at  any  time) 

•  by  termination  of  the  association. 

3.2.2.13  Element-Set-Names.  An  element  set  name  is  a  primitive  name  that  spec- 
ifies a  particular  subset  of  the  elements  in  a  database  record  that  are  to  compose  the  response 
records  Element  set  names  are  specified,  along.with  their  definitions,  for  a  given  database, 
by  the  target,  outside  of  this  standard.  The  target  specified  a  default  element  set  for  each 

The  parameter  Element-Set-Names  is  a  set  of  one  or  more  pairs  of  a  database  name  and 
associated  element  set  name.  For  each  database  record  returned  in  a  Search  (or  Present) 
response,  ifthe  given  database  is  specified  (as  a  component  of  one  of  the  pairs  comprising 
Element-Set-Names),  then  the  response  record  should  be  composed  according  to  the  corre- 
sponding element  set  name.  If  not,  the  response-record  should  be  composed  according  to  the 
default  element  set  name  for  that  database. 

The  parameter  Element-Set-Names  may  alternatively  consist  of  a  single  element  set 
name  (from  those  defined  by  the  target  system),  with  no  database  specified.  In  that  case,  for-, 
each  database  record  returned  in  a  Search  (or  Present)  response: 

•  if  the  specified  element  set  name  is"  valid  for  the  given  database,  the 
response-record  should- be  composed  according  to.  that  element  set 

name; 

•  if  the  specified  element  set  name  is  not  valid  for  the  given  database,  the 
response-record  should  be  composed  according  to  the  default  element 
set  name  for  that  database. 

3.2.2.1.4  Small-Set-Upper-Bound,  Large-Set-Lower-Bound,  and  Medium-Set-Pres- 
ent-Number (See  3.2.2.L6).  The  number  of  database  records  identified  by  the  resultset  is 
referred  to  as  the  result-count.  The  result  set  is  considered  either  a  "small  set,"  a  "medium 
set,"  or  a  "large  set,"  depending  on  Result-Count  and  the  parameters  of  the  search.  The 
result  set  is  a  small  set  if  Result-Count  is  not  greater  than  Small-Set-Upper-Bound.  The 
result  set  is  a  large  set  if  Result-Count  is  larger  than  or  equal  to  Large-Set-Lower-bound. 
Otherwise,  the  result  set  is  a  medium  set.         •   -" 

If  the  query  results  in  a  small  set,  all  database  records  identified  by  the  result  set  are  to 
be  returned  to  the  origin  (subject  to  possible  message  size  constraints).  If  the  query  results  in 
a  large  set,  no  database  records  are  to  be  returned.  If  the  query  results  in  a  medium  set,  the 
number  of  database  records  to  be  returned  is  specified  by  Medium-Set-Present-Number 
(which  does  not  exceed  Small-Set-Upper-Bound). 

The  use  of  these  three  parameters  is  illustrated  by  the  following  example.  Assume  that 
the  values  10  to  100  respectively  are  specified  for  Small-Set-Upper-Bound  and  Large-Set- 


to 


Lower-P.  .::. 
are  to  tx •  i .  ■ . 
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Lower-Bound.  If  the  search  results  in  ten  or  fewer  database  records,  then  all  database  records 
are  to  be  returned.  If  the  search  results  in  100  or  more  database  records  then  none  is  to  be 
returned.  Medium-Set-Prcsent-n umber  specifies  how  many  database  records  are  to  be  re- 
turned in  the  event  that  the  number  of  database  records  identified  is  between  1 1  and  99.  The 
requester  might  wish  to  specify  "if  there  are  ten  fewer  less  database  records,  send  them  all, 
but  if  there  are  more  than  10  (but  less  than  100)  send  only  two."  In  this  case,  Medium-Set- 
Present-Number  is  specified  as  2. 

3.2.2.1.5  Database/Diagnostic-Records.  The  target  processes  the  search,  creating  a 
result  set  that  identifies  a  set  of  database  records.  It  cannot  be  assumed,  however,  that  search 
processing  requires  physical  access  to  the  database  records;  thus  one  or  more  records  might 
not  be  returnable,  but  this  circumstance  might  not  be  recognized  until  an  attempt  is  made  to 
transfer  such  a  record. 

After  processing  the  search,  the  target  attempts  to  retrieve  the  first  N  records  identified 
by  the  result  set,  to  be  included  in  the  Search  response  (N  depends  on  the  search  parameters 
and  Result-Count,  as  described  in  section  3.2.2.1.4).  For  each  record  that  cannot  be  re- 
turned, a  diagnostic  record  is  substituted.  Thus  the  parameter  Database/Diagnostic-Records 
is  one  of  the  following: 

•  N  database  and/or  diagnostic  records, 

•  a  number  of  database  and/or  diagnostic  records,  which  is  less  than  N 
because  of  message  size  constraints  (see  section  3.3), 

•  a  single  diagnostic  record  indicating  that  the  search  cannot  be  pro- 
cessed, and  why  it  cannot  be  processed,  or 

•  a  single  diagnostic  record  indicating  that  records  cannot  be  presented, 
and  why  not. 

The  order  of  occurrence  of  records  (database  and/or  surrogate  diagnostic)  within  the 
parameter  Database/Diagnostic-Records  is  according  to  .tfie  order  in  which  they  are  identi- 
fied by  the  result  set.  Each  database  record  may  optionally  be  accompanied  by  the  name  of 
the  database  in  which  the  record  resides.  However,  the  database  name  must  accompany  the 
first  record  being  returned,  and  must  accompany  any  record  coming  from  a  database  dif- 
ferent than  its  immediate  predecessor. 

3.2.2.1.6  Result-Count  and  Number-of-Records-Returned.  The  parameter  Result- 
Count  is  the  number  of  records  identified  by  the  result  set.  If  the  result  set  is  empty,-  Result- 
Count  is  zero.  The  parameter  Number-of-Records-Returned  is  the  total  number  of  records 
(database  and  diagnostic)  returned  in  the  Search  response. 

3.2.2.1.7  Next-Result-Set-Position.The  parameter-Next-ResuIt-Set-Position  spec- 
ifies the  position  within  the  result  set  of  the  next  record  following  those  returned  (or  zero  if 
the  last  record  in  the  result  set  is  being  returned). 

3.2.2.1.8  Search-Status.  The  parameter  Search-Status  is  returned  in  the  response 
and  assumes  one  of  the  following  two  values: 

•  success — the  search  completed  successfully 

•  failure— the  search  did  not  complete  successfully. 

A  value  of  "success"  does  not  imply  that  the  expected  database  and/or  surrogate  diag- 


u 
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a        n,rlnr  the  response  (see  Present-Status,  section 

„  ."ST =^==-==  - 

lions.  .    .f  th    value  of  search-Status  is  "failure,"  and  its 

Result-Set-Status  occurs  if  and  oniy  u 

value  is  one  of  the  following: 

subset      _  Partial,  valid  results  available 

Interim    -  Partial  results  available,  not  necessarily  valid 

none        _  No  results  available. 

Present-Status  occurs  if  and  only  if  the  value  of  Search-Status  is  "success,"  and  its  value 
is  one  of  the  following: 


success     - 

partial- 1  - 

partial-2  • 

partial-3 

partial-4 

failure 


All  of  the  expected  database  (or  surrogate  diagnostic)  rec- 

N^aToTttetxUd  records  can  be  returned  because  the 
reauest  was  terminated  by  access-control. 
Not  ah  of  the  expected  records  can  be  returned  because  the 
reauest  was  terminated  by  maximum  message  size. 
ZaU  of  the  expected  records  can  be  returned  because  the 
reauest  was  terminated  by  resource-control  at  origin. 

.  nTSi  of  the  expected  records  can  be  returned  because  the 
request  was  terminated  by  resource-control  at  target 

-  None  of  the  expected  database  (or  surrogate  diagnostic)  rec- 
ords cL  be  returned.  A  single  diagnostic  is  returned,  which 
is  not  a  surrogate  for  a  database  record. 


3  2  2  1  10  Reference-ID.  See  section  3.4. 
3  2  3  Retrieval  Facility.  The  Retrieval  facility  enables  the  origin  to  retrieve  a  copy  of 
records  acting  I  position  within  a  result  set  maintained  by  the  target.  _ 

3.23,PresentServiceElem^^ 

to  retrieve  records  from  -J^^.^^X^Sevi  and  may  follow 
within  the  result  set.  The  ongin  specities  ^nSe  h      ri^n  may  rctneve 

^^^^^«=^^^  <"*  »  *  - 
greater  than  Result-Count  =  M  +  1). 

3.2.3.1.2'  Result-Sct-ID.  Result-Set-ID  specifies  the  result  set  from  which  records  are 
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Tabic  3 
Parameters  of  (he  Present  Service  Element 


PARAMETERS 


ORIGIN 
REQUEST 


TARGET 
RESPONSE 


Number-of-Records-Requcsted 

Result-Set-Start-Position 

Result-Set-ID 

Element-Set-Names 

Database/Diagnostic-Records 

Number-of-Records-Returned 

Next-Result-Sel-Position 

Present-Status 

Reference-ID 


x  (optional) 


x  (optional) 


x  (if  applicable) 

x 

x 

x 

x  (if  applicable) 


to  be  retrieved:  It  is  the  result  set  created  by  a  previous  Search  request  for  which  the  value  of 
the  parameter  Result-Set-Name  matches  the  value  of  Result-Set-ID. 

3.23.13  Element-Set-Names.  See  section  3.2.2.1.3. 

3.23.1.4  Database/Diagnostic-Records.  The  parameter  Database/Diagnostic-Rec- 
ords returned  by  the  target  consists  of  one  of  the  following: 

.    N  database  and/or  diagnostic  records,  where  N  =  Number-of-Records- 

Requested,  •■•  '    .      .  xr 

.    a  number  of  database  and/or  diagnostic  records,  which  is  less  than  N 

(reason  specified  by  Present-Status),  or  •     ;  .Vi 

.    a  single  diagnostic  record  indicating  that  the  request  cannot  be  proc- 
essed, and  why  it  cannot  be  processed.  <;.  . 

The  order  of  occurrence  of  records' (database  and/or  surrogate  diagnostic)  within  the  . 
parameter  Database/Diagnostic-Records  is  according  to  the  order  in  which  they  a« ;  idenU- 
fted  by  the  result  set  Each  database  record  may  optionally  be  accompanied  by  the  name  of 
the  database  in  which  the  record  resides.  However,  the  database  name  must  accompany  the 
first  record  being  returned,  and  must  accompany  any  record  coming  from  a  database.dif- 
ferent  than  its  immediate  predecessor. 

3  2  3  15  Number^f-Records-Returned  and  Next-Result-Sec-Position.  The  param- 
eter  Numbe'r-of-Records-Returned  is  the  total  number  of  database  and  diagnostic  records 
returned.  Next-Result-Set-Position  is  the- position,  within- the  result-set  of  the  next  record 
following  the  last  database  or  surrogate  diagnostic  record  being  returned  (or  zero,  if  the  last 
database  or  surrogate  diagnostic  record  in  the  result  set  is  being  returned). 

3.2.3.1.6  Present-Status.  Present-Status'  is  mandatory  in  a  Present  response  and  its 
values  are' trie  same  as  those  listed  for  Present-Status  in  section  3.2.2.1.9. 

3.23.1.7  Reference-ID.  See  section  3.4. 
3  2  4  Result-Set-Delete  Facility.  The  Result-Set-Delete  facility  enables  an  origin  sys- 
tem to  instruct  a  target  system  to  delete  a  result  set  known  to  the  target  system.  The  target 
system  responds  with  a  confirmation  message  or  an  error  report. 
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•     p.  mMlt  The  Delete  Service  element  enables  an  origin  system  to 
3.2.4.1  Delete  Service  Eleme  .tTteM^  ^        spedfic         u 

send  a  Delete  request  to  the  ^J^^^y  on  the  target  system  created  dunng 

$2S^^^^ thc  status  of  the  requcsled  delcte  opera" 

tion. 

Table  4 
Parameters  ofthe  Delete  Service  Element 


Delete-Operation 
Rcsult-Sct-ID 
Delete-Status 
Numbcr-Not-Delcted 

Bulk-Statuses 

Delete-MSG 

Reference-ID 


x  (if  applicable) 


x  (optional) 


x  (if  applicable) 


x  (if  applicable) 
x  (if  applicable) 
x  (optional) 
x  (if  applicable) 


3.2.4.1.1 


Delete-Operation.  The  origin  specifies  one  ofthe  following: 


•     i  Me-tr  a  soecific  result  set  (see  section/  3.2.4. 1 .2),  or 

^  Z  Sfeairesultsets  currently  on  the  target  system  created  dur- 
ing  this  association. 


S^Tor^te  olSe  ^  ,«suU  set  in  the  _ 


ues: 


success  — 
failure- 1  — 
failure-2  — 
failure-3  — 

failure-4  — 


failure-5 
failure-6 


Result  set(s)  deleted. 

Result  set  did  not  exist.  ,,.„»>♦ 

Result  set  previously  unilaterally  deleted  by  target. 
System  problem  at  target- (optional  text  message  may  be 
included  in  the  Delete-MSG  parameter). 
ActeJcontrol  failure:  the  delete  request  caused  the  target 
tSm  to  issue  an  Access-Control  request  that  the  ongm 
system  failed  to  satisfy,  or  the  origin  could  not  accept  an 
Arrpss-Control  request. 
_  Request  terminated  by  origin  system  through  resource  con- 

_  Access  terminated  by  target  system  due  to  resource  con- 
straints. 


If  Dei. 


3.2.-. i 
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Notc>.v 
not  deleted  .v 
first  failu"  •. 
status  mi  ;■.'••'• 
If  thc  !•« 
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Control  r.-qtu- 
targetsyslcm  : 
tion  did  no; 
Searcti.raV"'; 
with  an  S-.\  -"' 
before  rec-v- ' 
One:  :h. 
taken  pi"'-'- 
Present,  ■>■-  ■  • 
operation  ,--: 
respond  c-.; 
parameter  '■•• 
tion-Fiel-.'  .>' 
The  A, 
challenge:'-, 
tent  of  the 
standard. 

3.2.?.; 


14 


Mwi 


tfc.itf.m! 


'"'  "p.! ; 


\m& 


|V,,V.'! 


.... .*'*>: ::':.:•: :i^A?V.''  »i 


m-mww?* 


■fH 


i '-rv.;  ciV- 


i'(-;i 


ANSt/NISO  Z39. 50-1988 


If  Delcte-operation  is  "all,"  the  following  status  responses  are  also  possible: 

failure-7  —  Bulk  delete  of  result  sets  not  supported  by  target. 
failure-8  —  Not  all  results  sets  deleted  (see  3.2.4.1.4). 

3  2  4  14  Number-Not-Deleted  and  Bulk-Statuses.  If  Delete-Status  =t«hiluvo-S,n  the 
parameter  Number-Not-Deleted  indicates  how  many  result  sets  were  not  deleted,  and  the 
L.-o^w  RnlW  Statuses  rives  individual  statuses  for  those  not  deleted. 
P  Note  howe've?  thata target  system  is  not  obligated  to  provide  statuses  for  each  result  set 
not  de?et  J oTa ^bulk  delete.  For  example,  a  target  system  may  abort  a  bulk  delete  when  die 
Zt Se  to  delete  a  result  set  that  is  part  of  the  bulk  delete  fails;  m  this  case  only  a  single 
ctQtu.:  mioht  he  included  in  the  parameter  Bulk-Statuses. 

It  Zt ^uTk  deleteTesults  in  more  statuses  than  canfit  into  a  single  Delete  response 
message,  the  target  system  may  discard  those  which  do  not  fit. 

3.2.4.1.5  Delete-MSG.  Delete-MSG,  if  present,  contains  an  optional  text  message. 

3.2.4.1.6  Reference-ID.  See  section  3.4. 

3  25  Access  Control  Facility.  The  access  control  facility  allows  a  target  system  to 
challenge  an  origia  system  during  execudonofanlnit,  Search,  Present  orDeleteope *aUon 

An  origin  system  must  be  prepared  to  accept  a'nd  respond  to  one.  or  more =  Access 
Contort  request  while  an  Init,  Search,  Present,  or  Delete. request  is  being  executed  by  the 
SXS^less  the  parameter  Options  of  the  Init  request  which  initiated  the  connec- 
S  dd  noUnclude  access  control;  see  section  3.2.1.1.2).  For  example,  after  sending  a 
SeSch  request  the  origin  must  be  prepared  to  receive  an  Access-Control  request,  respond 
v^  an S-ControTresponse.tl.en  later  receive  another- Access-Control  request,  etc:, 

™°ZZZlS^  Snded,  the  operation  proceeds  a,  if  the  challenge  has  ^ver 
taken  pSce  If  the  origin  system.fails  to  respond  correctly  to  the  challenge  during  a  Search, 
^nfoTDdete  request,  then  the  Search,  Present,  or  Delete  response  will  indicate  thatthe 
option  was  terminated  due  to  an  access  control  failure.  If  the  ongm  «^ejn  faik  to 
reVpond  correctly  to  the  challenge  during  an  Init -request,  the  targe  will  set  the  Result 
parameter  to  "reject"  and  may  (optionally)  supply  such  an  indication  in  the  User-Informa- 
tion-Field  of  the  Init  response.  '     ■._  .  nnnrt  -.^LfH 

The  Access-Control  request/response  mechanism  can  be  used  to  support  Password 
challenges,  public  key  cryptosystems,  or  algorithmic  authentication  etc  ^e  ^cific  con- 
tent of  the  Access-Control  request  and  response  parameters  are  outside  the  scope  of  this 
standard. 

3.2.5.1  Access-Control  Service  Element 

TableS 
Parameters  of  Access-Control  Service  Element 


TARGET  ORIGIN 

PARAMETERS  REQUEST  RESPONSE 


Security-Challenge       .  x 
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permits  the  target  system  to  notify  the  on«w i  s  y£^eJ  ° ^^  and 
consumption  will  exceed  agreed  upon  Umite  ( °«  *  system  ^  inform  the 

obtain  the  origin  system's  consen  to ^^^  ^  ^iag  generated  on  the  target  u> 

22L2T.  t^*^^ about  the  status  of  the  current 

request. 

3.2.6.1  Resource-Control  Service  Element  to  ^  ^  Search) 

A  target  system  may  issue  a  .^^^So  the  Resource-Control  request, 

Delete,  or  Present  request  The  onjjn^m«  respond  t  ^^  as  if  the 

after  which  processing  continues   ^  Ac  pom  ^  ^  d  to  rcspoQd  to 

«*  ^origin  responds  to  a  Resource ^J^^^S^^S 
saying  to  terminate  the  command £can *p«*  to £*«  Present,  or  Delete  operatroa 

■•      (See  Table  6.)  ^^-v^  ,,<;ed  to  convey  information 

about  the  current  and  esumated  resou  rce  com      P  ^  an  cxamplc.    .. 

tteflas3p"rt«i:r-AvaUable,wBoseva1„eiSoaeofthefoUo™0.         ■ 

\ubset    -  partial,  valid  results  available 
interim  -  partial  reults  available,  not  necessarily  valid 
none      __  no  results  available. 


Resource-Report 

Suspended-Rag 

Parlial-Results-Availablc 

Continue-Flag 

Result-Set-Wanted 

Reference-ID 


x  (optional) 

x 

x  (If  applicable) 

x  (if  applicable) 


ORIGIN 
RESPONSE 


x  (if  applicable) 
x  (if  applicable) 


This  ••••'.•  •■•• 
"interim,1'  .'• 
terminate.'1   ;  ' 
Wanted  is  ■  -•' 
If  .th"  '••:"■•■• 
subsequer.:  '.":•  • 
Control  r"i'v  • 
Note  ••'■•:■:'•  i 
since  procr '•'•:•; 
Set-Status  i'.'.'.. 

.  3.1.?.:  • 
thecomrr.v- 

processir.r.. 


If  (he  •■-•■.••■ 
•"subsequer-!  ■<-:■: 

set.  A  resist  rt 

'  hasdiscaui'.ii1 

the  Searc'.-.  .rr;' 

which  the  '■'<■ ' 

•3^2.7  Tc:-V 


BotV, 
RELEA.:'-; 

3.X-" 
send  or  ; 

.     3.2.: 

follow:-: 
of  an  l': 
might  !• 
applies' 
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This  parameter  is  meaningful  only  during  a  search  operation.  If  its  value  is  subset  or 
"inteTim  "  Ten  the  target  will  aceept  subsequent  Present  requests  if  the  current  request  s 
te^inTted  by  the  Resource-Control  response  and  if  the  value  of  the  parameter  Result-Set- 

^"iflhe'vaTue  of  PartiaUResults-Available  is  "none"  then  the  target  need  not  accept 
subsequent  Present  requests  in  the  event  that  the  request  is  terminated  by  the  Resourc- 

C°n  Notelhatirsuspended-Flag  is  off,  the  partial  results  available  situation  may  change 
since  prolong  continues  on  the  search.  In  all  cases,  the  values  of  Search-Status  and  Result- 
SeSmus^  the  Search  response  should  be  treated  as  the  authoritative  information. 

3  2  6  13  Suspended-Flag.  The  target  system  indicates  whether  or  riot  processing  of 
the  command  has  been  suspended  pending  the  Resource-Control  response. 

3.2.6.1.4  Continue-Flag.  The  origin  indicates  to  the  target  whether  or  not  to  continue 
processing. 

3.2.6.1.5  Result-Set-Wanted.  This  flag  is  meaningful  only: 

«    during  a  Search  request,  ...      „       „•.-,. 

.    when  the  value  of  Partial-Results-Available  is  "subset    or    interim, 

.    when  the  value  of  the  parameter  Continue-Flag  is  "do  not  continue." 

If  the  value  of  the  flag  is  "on,"  the  target  will  maintain  the  (possibly  partial)  result  set  for 
subsequent  Present  requests:  If  the  value  of  the  flag  is  "off,"  the  target  may  delete  he  resul 
set  A  raut  set  status  of  "none"  on  the  subsequent  Search  response  indicates  that  the  target 
Ss  dis^rdeTiie  result  set.  In  all  cases,  the  values  of  Search-Status  and  Result-Set-Status  in 
Tc  Sea^hlesponse  describe  the  actual  decisions  made  ^y  the  target  system  and  the  way  m 
which  the  search  terminated. 

3.2.6.1.6  Reference-ID.  See  section  3.4. 
3.2.7  Termination  Facility.  The  Termination  facility  allows  either: 

(1)  an  origin  or  target  to  initiate  abrupt  termination  of  the  association  via    V- 
the  IR-Abort  service  element,  or 

(2)  an  origin,  system  to  initiate  graceful  termination  via  the  IR-Release 
service  element. 

Both  the  IR-Abort  and  IR-Release  services  map  directly  onto  the  A-ABORT  and  A- 
RELEASE  services  of  the  common  application  association  control  services. 

3  2  7  1  IR-Abort  Service  Element.  Either  the  origin  or  target  may  at  any  time  either 
send  or'receive  an  IR-Abort  request,  and  consider  the  application  associatton  terminated. 

3  272  IR-Release  Service  Element.  The  origin  may  invoke  an  IR-Release  request 
following  receipt  of  an  Init,  Search,  Present,  or  Delete  response.  It  should  then  await  receipt 
of  an  IR-Release  response,  and  then  consider  the  association  terminated.  Alternately  it 
might  receive  an  IR-Abort  request  from  the  target,  in  which  case  it  should  consider  the 
application  association  terminated. 
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•      an  in  Release  request  after  sending  an  [nil,  Search,  Present,  or 

Delete  rcspui     ,  oonsider  the  association  terminated. 

[R-Release  response,  and  consiaei  mi.  <>=>o 

.      •  ex-  K^fh  the  Search  and  Present  service  elements,  it  is 

3.3  Message  Size  ^^^^a^nZ^  of  database  record,  rerp.cs.ed 
possible  that  the  target  ml  not  be  able to  reru  responsible  for  packinE  as 

rtai^t.rsrlbe'rofreeordsiareoordne.erspaosrespoose.essa^.) 

„,„st„tioa.  Assume  tba,  the  target  ^™^^~^  Z- 

that: 

rH«  in  nnsition  1  through  6  fit  in  the  response  message,  such  that 

Irn^tinnWoes  not  exceed  Preferred-Message-Size;  but, 
IheT^tecTrd  in  position  7  will  not  fit  in  the  message  along  with 
*    f^^SZn  1  through  6  without  the  resulting  sum  of  the  mes- 
sage sizes  exceeding  Preferred-Message-Size. 

The  size  of  the  database  record  in  position  7: 

(*\  Ann  not  exceed  Preferred-Message-Size,  or 

fb)  exSerPrefcrred-Message-Size,  but  does  not  exceed  Maximum-Rec-   .      .    ■  ~  - 

ord-Size,  or 
(c)  exceeds  Maximum-Record-Size. 

,.  case(a),  the target "^^"Jg^jT^ substitutes  a diagnostic 
In  case  (b),  except  as  noted  below  (see   bxcepuon  i  B    ^  Preferred- 

record  for  the  database  record  m  posit, on  '.'»*£*««  « ^fM.he  database  record  in 

SSr  iuat'SreXMe^o ize  then  there  is  no  distinction  between  the  meaatng  of 
^  rStU  if  the  dtagnos  .^record  *U£*  -g  «nth  the ^j£*«. 

STl^- Xr^'r^^.'rrp.t V^  in  Positions  . 

through  10'into  the  response  message. 

Present  response.  Note  that  this  exception  applies  only  to  a  Present  reques 
Search  request.'' 


Thv   ; 
by  issur- . . 

No'.c  i:i 
imum-K  . . 
fashion:  •:' 
exceptic'i'-i' 
hold  loo.  '■  ': 
featedif  >i:'o 

3.4  Ref'ic- 
Delete  )■  •:;'.•■ 


IfF.!1'., 

not  to  •."'••-..■ 
intermc;:...:.i 

These" 
Search,  Pa- 
Present  or 

Thi:  p.- 
Referen,o-'t 
system. 


4.  Prcf^rni 

Thi::  -r 

The  !rf. 

govern!!;;',  .:'• 

unit  of  ;:.;•.•-•." 

dataur.il"  or 


4.1  Ab-.ii 

tOCOldr'U 

by  the  r- 
data  elcr. 
(section 

4.1.1   ■ 

tions,  r.- 
ditionf-'i 
others. 

T!v 
datatyiv 
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L      •  fh\  ,h-  nriein  may  subsequently  request  the  database  record  in  position  7, 

fashion,  with  convenient  buffcr  s^  ^  f^ ui?  the  origin  to  continually  allocate  and 
^K^Zrr^o  Jt  this  intend^  purpose  is  de- 
feated if  the  origin  routinely  requests  a  single  record.    .. 

^r  R  r ference-ID  is  optional  in  an  Init,  Search,  Present,  and 
££S»^  « '  «"»««.  .o  -8*  ^.ion,,  ^ 

Accetcontrol  or  Resource-Control  request/response  soqdenc.s. 

not  to  appear  in  **J^*J^u^ntio\  request/response  sequence, 
intermediate  Access-Control  or  Kesouru^        ,  7*     n  the  U  eference-ID  used  in  an  Init, 
Theservicedoesnotassumeany ^^   ^^r  Init,  Search, 
Search,  Present,  or  Delete  request  and  the  Reference 
Present,  or  Delete  request.  faHlitate  the  grouping  of  events  by  the  origin  system. 


system. 


4.  Protocol  Specification  .'•' 

data  unit"  or  APDU. 

toco!  data  nods  ate  comply ^^Thc  definitions  in  this  section  specify  the  component 

r:,e"h™ 

(section  4. 1.2). 

S»^&^  **  is  ^uired  in  some  circumsla"ccs  and  nM  req    '" 

"'""he  term  "ANY"  refers  .0  a  string  of  N  arbitrary  bits,  where  N  is  a  multiple  of  8;  no 
^'"-Uxt-'rrftlo  a  character  stri„B  composed  from  the  ASCII  repertoire  of  controi  and 
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•     rnmY^)  Only  the  character  repertoire,  and  not  the 
graphic  characters  (i.e.,  the  repertoire  from  X3.4).  Only 

^£^3*  ,o  a  character  string  £P  »  «*£^4  ^f vJuTan 

repert^  represente^^^^^^ 

identifier,  the  upper  and  lowe^™    *     whose  value  is  between  zero  and  16.777.21X 


4.!. 


4.1.1.1  InitAPDU 


Table  7 
Abstrac^ta^ofjhejnit^^ 

R/O/C  Value/Usage 


PDTJ-Type 
Protocol-Version 

Options 


Preferred-Message-Size 
Maximum-Record-Size 

ID/Authentication 
Implementation-ID 

Implementation-Name 

Implementation- Version 

Reference-ID 
User-Information-Fveld 


R 
R 

O 
O 

O 

O 


20— Init 

see  note  below 

a  string  of  boolean  values.  0-   wu 

not  us^"  and  1=  "will  use"  for  each  of: 

search 
••  present 

delete  „    ... 

0  =  "will  not  support"  and  I  =   will 
support"  for  each  of: 

access-control 

resource-control 

integer         ,■ 

integer,  must  equal  or  exceed- 
Preferred-Message-Size  if  present 
ANY;  maximum  64  bytes 
identifier,  a  unique  identifier  for 
the  origin  implementauon 
identifier;  a  descriptive  name  for  the 

origin  implementation 

identifier;  a  desenpuve  name  for  the 

origin  implementation  version 

ANY;  maximum  64  bytes 

ANY 


ser-Information-f  leiu  . . = — : .       -me  first  value  set 


/ 


Element 

PDU-Tyr'.- 
Result 
Protocol-V<- 
Options 


Preferro".->K.^ 
Maximv' "•-'•"" ' 

lmplemcn;.ti-. .: 

Implcmc  n'.:-.  ■..-.". 

Implemci'i:' 

Reference  -ID 
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4.1.1.2  lait-Response  APDU 


Tabic  8 
Abstract  Syntax  of  the  Init-Response  APDU 


PDU-Type 

Result 

Protocol-Version 

Options 


Preferred-Message-Size 
Maximum-Record-Size 

Implementation-ID 

Implementation-Name 

Implementation- Version 

Reference-ID 
User-Information-Fidd 


R 
R 

O 

O 

O 

C 

O 


lues,  u —  «••• 

"wilt  support"  for  each  of: 


21  =  I  nit- Response 

I  =  "accept",  0  =  "reject" 

see  note  in  4.1.1.1  u 

a  string  of  boolean  values.  0—  will^ 

not  support"  and  1— "will  support 

search 

present 

delete  „ 

0— "will  not  use"  1— " will  use    lor 

each  of: 

access-control 
•  resource-control 
integer 

integer,  must  equal  or  exceed 
Preferred-Message-Size 
identifier,  a  unique  identifier  for 
the  target  implementation 
identifier,  a  descriptive  name  for  the 
target  implementation 
identifier,  a  descriptive  name  for  the 
target  implementation  version 
ANY;  identical  to  Reference— ID  in  the 
Init  APDU 
ANY 
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4.1.1-3  Search  APDU 


Element 


Table  9 
Abstract  Syntax  of  the  Search  APDU 

Value/Usage 


PDU-Type 

Small-Set-Upper-Bound 

Large-Set-Lower-Bound 

Medium-Set-Present-Number 
Replace-Indicator 

Result-Set-Name 
Database-Names 
Query-Type 

Element-Set-Names 


Reference-ID 
Query 


R/O/C 

R 
R 
R 

R 

R 

R 
R 
R 

O 


O 
R 


22  =  Search 

integer 

integer,  greater  than  small-set- 

uppcr-bound  unless  both  are  zero 

integer,  less  than  or  equal  to 

small-set-upper-bound 

0  =  "off;  1  =  "on".  Must  be  "on"  if 

Result-Set-Name  =  "default" 

identifier 

one  or  more  identifiers 

0  =  Type'-O,  1  =  Type-1 .  Other  types 

are  for  future  study  and  standardization. 

a  single  element  set  name,  or  one  or 

more  pairs  of  (database  name,  element 

set  name);  each  element  set  name  and 

each  database  name  is- an  identifier 

ANY;  maximum  64  bytes 

structure;  structures  for  query-types 

Type-0  and  Type- 1  are  specified  in 

section  4. 1..2. 


Elcmen: 

PDU-T;..- 

Number-  .••'. 

Result-.Su- 

Result-S-. 

Elemen'-'" 

Referen-;y 


4.M. 


Element 

PDU-Tyiv 
Present-'-' -i.. 
Number-^ ;: 
Next-Rr.i.: 

Referen;;'- 


4.1.1.4  Search-Response  APDU 


Databa.-.-.-' 


Table  10 


4.1.! 


Element 

R/O/C 

Value/Usage 

PDU-Type 

Search-Status 

Result-Count 

Number-of-Records-Returned 

Next-Result-Set-Position 

Result-Set-Status 

Present-Status 

Reference-ID 
Database/Diagnostic-Records 

R 
R 
R 
R 
R 
C 
C 

C 
C 

23  =  Search-Response 
0  =  "success",  I  =  "failure" 
integer 
integer 
integer 

1  =  "subset",  2  =  "interim",  3  =  "none 
0  =  "success",  1  =  "partial-1",  2  = 
"partial-2",  3  =  "partial-3",  4  = 
"partial-4",  5  =  "none" 
.  ANY;  identical  to  Reference-ID  in  the 
Search  APDU 
see  section  3.2.2.1.5. 

Element 

PDU-T;-' 

Delete-C,::.' 

Result-S:' 

Referen c:  '■'. 


22 


'.!-,i->-:' J 


1  '  •••?;; 


:■».•£''■••.•;'■>•  -r>"-\  V-'..  ••  >'ii, A  ...  " 


'  'V'^^ri^^A^i 


■-■      '    >  '  f.',,   ■,  ,   '.-■■.'' 


!^.V;->w^ 


KaPK '" 


ANSI/NISO  Z39. 50-1988 


4.1.1.5  Present  APDU 


Element 


Table  11 
Abstract  Syntax  of  the  Present  APDU 

Value/Usage 


PDU-Type 
Number-of-Records-Requested 

Result-Set-Start-Position 
Result-Set-ID 
Element-Set-Names 
Reference-ID 


R/O/C 


R 
R 
R 
R 
O 
O 


24  =  Present 

integer 

integer  • 

identifier 

see  section  4.1.1.3 

ANY;  maximum  64  bytes 


;    I 


4.1.1.6  Present-Response  APDU 


Table  12 
Abstract  Syntax  of  the  Present-Response  APDU 


Element 


PDU-Type 

Present-Status 

Nuraber-of-Records-Returned 

Next-Result-Set-Position 

Reference-ID 

Database/Diagnostic-Records 


4.1.1.7  Delete  APDU 


R/O/C 


Value/Usage 


R  25  ==  Present-Response 

R  see  section  4.1.1.4 

R  integer 

R  integer 

C  ANY;  identical  to  Reference-ID  in  the 

Present  APDU 

C  see  section  3.2.3.1.4 


Table  13 
Abstract  Syntax  of  the  Delete  APDU 


Element 


PDU-Type 
Delete-Ope  ration 
Result-Set-ID 


Reference-ID 


R/O/C 


Value/Usage 


R  26  =  Delete 

R  1  =  "single",  2  =  "all" 

C  identifier,  present  if  and  only  if  Delele- 

Operation  =  1 
O  ANY;  maximum  64  bytes 
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4.1.1.8  Delctc-Rcsponsc  APDU 


PDU-Typc 
Delete-Status 


Rcsult-Set-ID 


Tabic  14 
Abstract  Syntax^HhcDelc^s^^^ 


Number-Not-Deleted 
Bulk-Statuses 


Delete-MSG 
Reference-ID 


C 
C 


O 
C 


27  =  Delete-Response 
0  =  "success",  1  =  "failure- 1", 
2  =  "failure-2",  3  =  "failure-3^, 
4  =  "failure-4",  5  =  "failure-5  , 
6  =  "failure-6",7  =  "failurc-7  , 

fdTntifiS  Wcntical  to  R^^^'TnW  if 
Delete  APDU,  and  present  if  and  only  if 
Delete-Operation  was  1        .._..„  status  = 
integer,  present  if  and  onl> - . _f  Delete-Status 
„„.  or  more  pairs  of  (identifier, 
inTegerXsce  Action  3.2.4.1.4;  present  if  and 
only  if  Delete-Status  =8 
contains  a  text  message 
ANY;  identical  to  Reference-ID  m  the 
Delete  APDU 


Element 

PDU-Typc 
Suspended  ! 

Resource-}' .' 
Partial-Re"' 
Reference-' ' 


Element 

PDU-Typc 
Continue-!"'";; 
Result-Set-  W.i: 


4.1.1.9  Access-Control  APDU 


4.1.1.10  Acces 


s-Control-Response  APDU 
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4.1.1.11   Resource-control  APDU 


Table  17 
Abstract  Syntax  of  the  Resource-Control  APDU 


Element 


R/O/C 


Value/Usage 


PDU-Type 
Suspended-Flag 

Resource-Report 

Partial-Results-Available 

Reference-ID 


R 
R 

O 
C 
C 


30  =  Resource-Control 

1  =  "operation  suspended",  2  = 

"operation  not  suspended'1 

contains  a  text  message 

1  =  "subset",  2  =  "interim",  3  =  "none' 

ANY",  identical  to  Reference-ID  in  the 

Init,  Search,  Present,  or  Delete  APDU 

that  initiated  the  current  operation 


Element 


4.1.1.12  Resource-Control-Response  APDU 

Table  18 
Abstract  Syntax  of  the  Resource-Control-Response  APDU 

Value/Usage 


R/O/C 


PDU-Type 

Continue-Flag 

Result-Set-Wanted 


Reference-ID 


R 
R 
C 


C 


31  =  Resource-Control-Rcsponse 
1  =  "continue",  2  =  "do  not  continue" 
[  =  "yes",  0  =,"no";  required  during  a 
search  operation  if  value  of  Continue- 
Flag  is  "no" — otherwise  should  not  be  present 
ANY;  identical  to  Reference-ID  in  the 
Resource-Control  APDU 


4.1.2  Abstract  Syntax  of  the  Type-1  and.Type-0  Queries 

4.1.2.1  Type-1  Query  Structure.  In  the  definition  of  "query"  below: 

:  =    means  "is  defined  as," 
/      means  "or," 

+   means  "followed  by,"  and 

+    has  precedence  over  /  (i.e.,  +  is  evaluated  before  /).      ' 

The  Type- 1  query  is  defined  as  follows:  ■ 

query     :  =  argument /argument  +  argument  +  Operator 

argument    :  =  operand  /  query 
operand     :  =  Attribute-List  +  Term  /  Result-Set-ID 


Attribute-List 

Term 

Result-Set-ID 

Operator 


=  identifier 

=  ANY 

=  identifier 

=  AND/OR/AND-NOT 


25 


ANSI/NISO  Z39. 50-1988 


Notes: 


1.  "Query"  is  recursively  defined;  it  is  either 

(a)  "operand,"  or 

(b)  "argument  +  argument  +  operator." 

In  case  (b),  each  occurrence  of  "argument"  can  be  replaced  by  either 
(a)  or  (b)  and  so  on.  A  structure  composed  of  operators  and  operands 
conforms  to  the  Type-1  query  syntax  if  and  only  if  it  is  possible,  by 
repeatedly  replacing  occurrences  of  (b)  with  (a),  to  reduce  the  structure 

2.  "Operand"  is  either  (a)  Attribute-List  +  Term,  or  (b)  Result-Set-ID.  In 
'  either  case  it  represents  a  set  of  database  records.  For  (a)  it  is  the  set  of 

database  records  obtained  by  evaluating  the-specified  attribute-list  and 
term  against  the  collection  of  databases  specified  in  the  search  request. 
For  (b)  it  is  the  set  of  database  records  represented  by  the  result  set  for 
which  Result-Set-ID  was  specified  as  the  value  of  the  parameter  Re- 
sult-Set-Name in  the  current  or  a  previous  Search  request. 

3.  An  example  of  an  attribute-list  for  use  with  the  Type-1  query  is  given 
in  appendix  C. 


4.J."-. 
target  b«v. 
to  the  tr.rp 


4  12  11  Query  Evaluation.  The  Type-1  query  is  a  reverse-polish-notation  (RPN) 
structure. 'Evaluation  of  operands  and  operators  is  illustrated  by  the  use  of  a  stack.  The 
query  is  evaluated  left-to-right.  Each  query-term  is  one  of  the  following: 

(1)  Attribute-List  +  Term  "   -: 

(2)  Result-Set-ID 

(3)  Operator.  <■' 

Whenever  (1)  is  encountered,  it  is  evaluated  against  the  collection  of  databases  specified 
in  the  Search  request,  and  the  result  is  put  on  the  stack. 

Whenever  (2)  is  encountered,  it  is  put  on  the  stack. 

Whenever  (3)  is  encountered,  the  last  two  items  (i.e.,  sets,  see  note  2  above)  that  have 
been  put  on  the  stack  are  pulled  off  and  the  operator  is  applied  as  follows: 

«    if  Operator,  is  AND,  the  result  is  the  intersection  of  the  two  sets,  - 

•  •  if  Operator  is  OR,  the  result  is  the  union  of  the  two  sets, 

•  if  Operator  is  AND-NOT,  the  result  is  the  set  of  elements  in  the  first  set 
which  are  not  in  the  second  set. 

The  resulting  set  is  then  put  on  the  stack.  .• 

When  evaluation  of  the  query  is  complete  (i.e.,  all  query-terms  have  been  processed) 
there  will  be  one  item  remaining  on  the  stack  (otherwise  the  query  is  in  error),  which  is  the 
result  of  the  query. 
Examples:  , 

The  following  examples  illustrate  query  evaluation.  In  these  examples,  D  represents  tne 
collection  of  databases  specified  in  the  Search  request,  R  represents  a  Result-Set-ID,  and  A, 
B,  and  C  represent  attribute-list/term  combinations  such  as  "subject  -  dogs." 


4.13  ;*k 
the  data  rU" 


Element 

PDU-Ty;v  .• 
Referenc;  •!;!> 
Protocol  -Vci: 

Options 

Preferrc:!-M. 

Maximu  n-i-: 

ID/Auth-i-;. 
Implem?;  •:,: 


[mplero'.vil . 

Implemc:.'  • 

User-In'.  !■• 

Result 
Small-S-.-'-' 
Large-S; ,  : 
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1.  Query  =  A 

Result:  the  records  in  D  for  which  A  is  true 

2.  Query  =  ABCANDOR 

Result:  the  records  in  D  for  which  both  B  and  C  are  true,  or  A  is 
true 

3.  Query  =  AB  AND  C  OR 

Result:  the  records  in  D  for  which  both  A  and  B  are  true,  or  C  is 
true 

4.  Query  =RA  AND 

Result:  the  records  in  D  for  which  both  (1)  A  is  true,  and  (2)  which 
are  also  in  result  set  R 

5.  Query  =  RAOR 

Result  the  records  in  D  for  which  A  is  true,  together  with  the  rec- 
ords in  result  set  R 

4.1.2.2  Type-0  Query  Structure.  A  Type-0  query  may  be  used  only  when  the  origin  and 
target  have  an  a  priori  agreement  outside  of  this  standard  as  to  the  form  of  query  acceptable 
to  the  target 


Item 
Query 


Values 
ANY 


4.13  Tag  Values  of  the  APDU  Data  Elements.  Table  19  specifies  tag  values  (integers)  for 
the  data  elements  of  the  Information  Retrieval  APDUs. 

Table  19  (,. 

Data  Elements  and  Their  Tags' 


Element 


Tag 


PDU 


R/O/C 


PDU-Type 

Reference-ID 

Protocol-Version 

Options 

Preferred-Message-Size 

Maximum-Record-Size 

ID/Authentication 
Implementation-ID 

Implementation-Name 

Implementation-Version 

User-Information-Ficld 

Result 

Small-Set-Upper-Bound' 

Large-Set-Lowcr-Bound 


1 

2 
3 

(all  PDUs) 
(all  PDUs) 
Init 

4 

Init-Response 
Init-. 

5 

Init-Response 
Init 

6 

Init-Response 
Init 

7      , 

Init-Response 
Init 

8 

Init 

9 

-  •-'Init-Response 
Init 

10 

Init-Response 
Init 

11 

Init-Response 
Init 

12 
13 

Init-Response 
Init-Response 
Search 

14 

Search 

R 

C 

R. 

rv- 

R' 

R 

R 

R 

R 

R 

O 

O 

O 

O 

O 

O 

O 

O 

O 

R 

R 

R 
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Tabic  19 
Continued 


Medium-Set-Present-Numbcr 

Replacc-lndicator 
Result-Set-Name 
Database-Names 
Element-Set-Name 

Query-Type 

Query 

Search-Status 

Result-Count 
Number-of-Records-Returned 

Next-Result-Set-Position 

Result-Set-Status 
Present-Status 

Database/Diagnostic-Records 

Number-of-Records-Requested 

Result-Set-Start-Position 

Result-Set-ID 


Delete-Operation 

Delete-Status 

Number-Not-Deleted 

Bulk-Statuses 

Delete-MSG 

Security-Challenge 

Security-Challenge-Response 

Suspended-Flag 

Resource-Report 

Partial-Results-Available 

Continue-Flag 

Result-Set-Wanted 

Attribute-List 

Term 

Operator 


15 
16 
17 
18 
19 

20 
21 
22 
23 
24 

25 

26 

27 

28 

29 
30 
31 


32 
33 
34 
35 
36 

37 

38 

39 

40 

41 

42 

43 

44' 

45 

46 


Search 
Search 
Search 
Search 
Search 
Present 
Search 
Search 

Search-Response 
Search-Response 
Search-Response 
Present-Response 
Search-Response 
Present-Response 
Search-Response 
Search-Response 
•  Present-Response 
Search-Response 
.  Present-Response 
Present 
Present 
Present 
Delete 

Delete-Response 
(Type- 1. query) 
Delete 
,     Delete-Response 
Delete-Response 
Delete-Response 
Delete-Response 
Access-Cpntrol 
Access-Control-Response 

Resource-Control 

Resource-Control 

Resource-Control 

Resource-Control-Response 

Resource-Control-Response 

(Type- 1  query) 
(Type-1  query) 
(Type- 1  query) 


R/O/C 

R 
R 
R 
R 
O 
O 
R 
R 
R 
R 
R 
R 
R 
R 
C 
C 
R 
C 
C 
R 
R 
R 
C 
'  C 
C 
R 
R 
C 

C," 

O 

R 

R 

R 

O 

C 

R 

C 

-C 

"C 

C 


4.2.5  1  • 
thecomr"  •". 
services  r  •  ■•■' 


The  ?■■;•  •. 

Informalk;:i 

.     It  is  ;.t!-..v; 

control  se; •••;•. 

ing  the  Info:1 

4.2.2  F.r.-l 
pendent  c;"";i 

A  servi.' 
primitive  ''■■"• 
There  .;;; 


4.2  Protocol  Procedures 
4.2.1  Services  Required 

«.m.  se„lce  ■**-  ,m  «h.  -T«>°»  »^s  rr:s: 

^ 'TiZ^:Sn  Re.rieva,  pro.pco.  dau  nto  «UI  be  m,pped  0„«0  Che  P-Da,,  service. 
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4  2.1.2  Common  Application  Services  Assumed  The  protocol  assumes  *J  £™«^f 
the  common  application  association  control  service  elements  as  defined  in  ISO  8649/2.  The 
services  required  are: 

1)  association  establishment,  to  allow  the  origin  and  target  to  establish  an 
application  association, 

2)  orderly  association  release,  where  both  sides  agree  to  the  release  and 
there  is  no  loss  of  data  in  transit  (the  IR-Release  service  is  directly 
mapped  to- this  service  without  any  Information  Retrieval  protocol 
control  information),  and 

3)  association  abort,  which  allows  either  origin  or  target,  at  any  time,  to 
explicitly  terminate  the  association,  immediately  and  unconditionally. 
Data  m  transit  may  be  lost  (the  IR-Abort  service  is  directly  mapped  to 
this  service  without  any  Information  Retrieval  protocol  control  infor- 
mation). 

The  service-user  will  invoke  the  common  application  service  elements  directly.  The 
r  fn^TStriTJd  service  does  not  invoke  any  common  application  service  elements. 
Us ^^umS  thttThTSformation  Retrieval  serVic  user  will  handle  the  association 
cont  o  se'^uired  to  establish  an  association  with  an  application  context  encompass- 
ing the  Information  Retrieval  service  and  to  release  or  abort  the  association. 

4  2  2  Protocol  Model.  To  specify  protocol  procedure,  the  abstract,  implementetion-inde- 
nendent  concepts  of  service-user,  service-provider,  and  service  primitive  are  used. 
P      r^provider  provides  a  communication  path  between  two  service  users.  A  service 
primttive  is  an  element  of  interraction  between -the  service-user  and  the  service-providers 

There  are  four  types  of  service  primitives: 

t.r 

1)  Request-A  primitive  issued  by  the  origin  service-user  to  the  service- 
provider  in  order  to  invoke  some  procedure         •         . 

2)  Indication-A  primitive  issued  by  the  service-provider  to  the  target 
service-user  to  indicate  that  a  procedure  has  been  invoked  by  its  peer 

3)  Response-A  primitive  issued  by  the  target  service-user  to  the  service-       v  . 
provider  at  the  completion  of  the  procedure  previously  invoked  by  an 

indication  .  („,(K„ 

4)  Confirmation-A  primitive  issued  by  the  service-provide    to  the 
origin  service-user  to  complete  the  procedure  previously  invoked  by  a  . 
request. 

Primitives  are  conceptual  and  their  use  neither  specifies  nor  precludes  any  specific 
implementation  of  a  service.  Only  primitives  that  correspond  to  some  element  of  the  service 
involving  the-exchange  of  information  between  systems  are  defined 

From  the  perspective  of  the  service-user,  the  service-provider  is  system-independent. 
For  the  exchange  of  protocol  however,  a  distinction  is  made  between  ^POT^ons  <jf  £ 
service-provider  residing  on  the  origin  and  target  systems  (respectively,  the  ongin^ service 
provider  and  the  larger  service-provider).  See  Figure  1 .  The  sequence  of  interactions  is. 
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1 )  Request  Primitive  from  origin  service-user  to  service-provider 

2)  Protocol  Message  from  origin  service-provider  to  target  service- 
provider 

3)  Indication  Primitive  from  service-provider  to  target  service-user 

4)  Response  Primitive  from  target  service-user  to  service-provider 

5)  Protocol  Message  from  target  service-provider  to  origin  service- 
provider  ... 

6)  Confirmation  Primitive  from  service-provider  to  ongtn  service-user 


Thefo 


illustrates  the  sequence  of  interactions' which<jccurJbr>Search  opera- 


tion: 


1)  Search  request  from  origin  service-user  to  service-provider 

2)  Search  APDU  (Application  Protocol  Data  Unit)  from  origin  service- 
provider  to  target  service-provider  ^. 

3)  Search  indication  from  service-provider  to  target  service-user 

4)  Search  response  from  target  service-user  to  service-provider 

5)  Search-Response  APDU  from  target  service-provider  to  origin  service- 
provider 

6)  Search  confirrmfrom  service-provider  to  origin  service-user. 

NOTE-  The  interfaces  between  service-user  and  service-provider,  as  represented  by  steps  1 
and  6  for  the  origin,  and  by  steps  3  and  4  forthe  target,  are  described  solely  to  facilitate  the 
specification- of  protocols.  These  steps  do  not  represent  intersystem  communication,  and 
therefore  the  means  by  which  they  are  implemented  are  not  constrained  by  this  specifica- 
tion In  an  actual  implementation,  step  4,  for  example,  might  consist  of  several  messages 
from  the  target  service-user  to  service-provider.  On  the  other  hand,  both  the  target  service 
user  and  service-provider  could  be  combined  in  a  single  program,  in  which  case  steps  3  and  4 
might  not  have  any  real  physical  manifestation. 


4. 2 J  f . 
(IRPMs)'.. 
state  tab';-  ! 
between '.' 
the  protc 
state  tab-, 
more  pre'- 
state  tab".  >■ 


Thcv" 
as  used  ;n 
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,  o,  .    t  ,  i„c  ThU  action  defines  two  Information  Retrieval  Protocol  Machines 

4.2  3  State  ™"-™»^™*°mc  table  is  defined  for  the  origin  (Table  22)  and  one 

(IRPMs)  m terms  of  s  ate  ™£°»'%  Each  sUtc  table  shows  the  interrelationship 

more  prtis.  s^cification  of  the  protocol  procedures.  The  following  conventions  are  used  m 
state  tables: 

Slat%Zb interaction  of  an  incoming  event  .(row)  and  a  state  (column) 
forms  a  cell.  A  blank  cell  represents  the  combination  of  an  incoming 
vent  and  a  state  that  is  not  defined  for  the  IRPM  A  aonWank  odl 
represents  an  incoming  event  and  state  that  is  defined  for  the  IRPM.  Such 
a  cell  contains  one  or  more  actions,  separated  by  semicolons  (;). 

Actions  to  be  Taken  by  the  IRPM 

The  IRPM  state  tables  define  the  action  to  be  taken  by  the  IRPM  in 
terms  of  one  or  more  outgoing  events  (separated  by  semicolons)  and  the 
resulting  state  (in  parentheses)  of  the  Information  Retrieval  associaUon. 

Invalid  Intersections  <     .  .  . 

Blank  cells  indicate  an  invalid  intersection  ofan  incoming  event  and 
state  The  state  tables  define  correct  operation  only.  They  do  not  specify 
actions  to  be  taken  in  response  to  incorrect  operation  (for  example,  er- 
roneous protocol  control  information,  incorrect  protocol  control  actions 
etc.).  Such  actions  are  not  within  the  scope  of  the  specification,  although 
implementations  must  consider  them.  ,,-••, 


Table  20 
Events  and  Actions 


I 


The  following  tables  list  the  events  and  actions  which  occur  in  the 
as  used  in  the  state  tables: 

Incoming  Events— Origin 
Ink  request  v 

I  nit- Response  PDU 
Search  request 
Search-Response  PDU 
Present  request 
Present-Response  PDU 
Delete  request 

Delete- Response  PDU 
-•■      Resource-Control  PDU 

Resource-Control  response 

Access-Control  PDU 

Access-Control  response 

P-P-Abort  indication 

IR-Abort  request 

IR-Release  request 

A-Release  confirm 


state  tables  and  their  abbreviations 

Abbreviation 
Init  req 

Init  resp  PDU   ' 
Srch  req 
Srch  resp  PDU 
Prsnt  req 
Prsnt  resp  PDU 
Dlte  req 
Dlte  resp  PDU 
Rsc  PDU 
Rsc  resp 
Ace  PDU 
Ace  resp 
Pab  ind 
lab  req 
Irel  req 
Arel  conf 
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Tabic  20 
Continued 


Outgoing  Actions— Origin 

Init  PDU 

[nit  confirm 

Search  PDU 

Search  confirm 

Present  PDU 

Present  confirm 

Delete  PDU 

Delete  confirm 

Resource-Control  indication 

Resource-Control-Response  PDU 

Access-Control  indication 

Access-Control-response  PDU 

IR-Abort  indication 

A-Abort  request 

A-Release  request 

IR-Release  confirm 

Save  current  state 

Restore  previously  saved  state 

Incoming  Event— Target 
Init  PDU 
Init  response 
Search  PDU 
Search  response 
Present  PDU 
Present  response 
Delete  PDU 
Delete  response 

Resource-Control  request         .    . 
Resource-Control-Response  PDU 
Access-Control  Request 
Access-Control-Response  PDU 
P-P-Abort  indication 
IR-Abort  request 
A-Relcase  indication 
IR-Release  response 

Outgoing  Action — Target 
Init  indication 
Init-Response  PDU 
Search  indication 
Search-Response  PDU 
Present  indication 
Present-Response  PDU 
Delete  indication 
Delete-Response  PDU 
Resource-Control  PDU 
Resource-Control  confirm 
-  Access-Control  PDU 

Access-Control  confirm 

IR-Abort  indication 

A-Abort  request 

IR-Release  indication 

A-Release  response 

Save  current  state 

Restore  previously  saved  state 


Abbreviation 
Init  PDU 
Init  conf 
Srch  PDU 
Srch  conf 
Prsnt  PDU 
'  Prsnt  conf         - 

Dlte  PDU 

Dlte  conf 

Rsc  ind 

Rsc  resp  PDU 

Ace  ind 

Ace  resp  PDU 

lab  ind 

Aab  req 

Arel  req 

Irel  conf 

stkst 

popst 

Abbreviation 

Init  PDU 

Init  resp 

Srch  PDU 

Srch  resp 

Prsnt  PDU 
•     Prsnt  resp 

Dlte  PDU 

Dlte  resp 

Rsc  req 

Rsc  resp  PDU 

Ace  req 
■'     Ace  resp  PDU 

Pab  ind 

lab  req 

Arel  ind 

Irel  resp 

Abbreviation 
Init  ind 
Init  resp  PDU 
Srch  ind 
Srch  resp  PDU 
Prsnt  ind 
Prsnt  resp  PDU 
Dlte  ind    ' 
Dlte  resp  PDU 

Rsc  PDU 

Rsc  conf 

Ace  PDU 

Ace  conf 

lab  ind 

Aab  req 

Irel  ind 

Arel  resp 

stkst 

popst 


Origin  st«';-i 

1.  Closed;  ;h 

2.  Init  se:-,s   ;:.. 

3.  Open:  ':•  • 

4.  Search  -.< 

5.  Prsnt  ?:r:   ; 

6.  Delete  :<-  • 

7.  Rsctrl  i>-.v.i. 

8.  Acctrl    ••     '■ 

9.  Rlease  :.  .•;  : 

Target  stft  •. 

1.  Closed-  I'c-  : 

2.  Init  rc<-\v:  il 

3.  Open:  :!•••  a 

4.  Search  :-.•.  ••<.< 

5.  Prsnt  ro-. .! 

6.  Delete  r»-.-- ..: 

7.  Rsctrl  s-v 

8.  Acctrl  io./.. 

9.  Rlease  rU;  ■. 


Event 


Inii 
req 


'  In'r. 

resp 
,;  PDl: 
(ACCEi-l 


Init 
resp 
PDl: 

(rejec  r; 


Srch 
req 


Srcr 

resp 
PDi: 
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Tabic  21 
Definition  of  States 


Origin  states  .   .   reauest  from  the  application 

,.  Closed:  the  origin  '\awf '"^^ninit  APDU  to  the  target 

2.  Init  sent:  the  origin  ^}nnsm^ch?\cLi,  or  Delete  request 

3.  Open:  the  origin  »  ^^^JX*  APDU 

4.  Search  sent:  the  origin i  has  wnsra'ttea  ApDU 

5.  Prsnt  sent:  the  ongin  has  transmitted  a  r resc 

6.  Delete  sent:  the  origin  ^^^t^ce-C^ntrol  indication 

7.  Rsctri  recvd:  the  origin  has  ^"^^.Qmtrol  indication 

8.  Acctrl  recvd:  the  ™\h™.^™X^  request 

9.  Rlease  sent:  the  origin  has  issued  an  a  r. 

Target  states  .,  .  .    apdU 

7.  Rsctri  sent  Ihe  urgM  h"  u.°™  >  «>  ■  ' ^Z^-CoMot  APDU 


2. 
3. 
4. 
5. 
6. 
7 


Table  22 
State  Table  for  Origin  Systems 


State 


Closed 


Delete      Rsctri      Acctrl      Rlease 
recvd        recvd         sent 
789 


Event 
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Tabic  11 
Continued 

Stale 

Closed 

1 

Event 

Init 
sent 

2 

Open 
3 

Search 

sent 

4 

Prsnt 

sent 

5 

Delete 

sent 

6 

Rsctrl 
reevd 

7 

Acctrl 

reevd 

8 

Rlease 

sent 

9 

Prsnt 
req 

Prsnt 

PDU 

(5) 

Prsnt 
resp 
PDU 

Prsnt  • 

conf 

(3) 

• 

Dlte 

req 

Dlte 

PDU 

(6) 

Dlte 
resp 
PDU 

- 

Dlte 

conf 

(3) 

Rsc 
PDU 

Rsc 

ind; 

stkst 

(7) 

Rsc 
ind;  • 
stkst 
(7) 

Rsc 
ind; 

stkst 
(7) 

Rsc 
ind; 
stkst 

'     (7) 

Rsc 
resp 

Rsc 
resp 

PDU; 

popst 

''  •'-.-- 

Ace 
PDU 

Ace 

ind; 

stkst 

(8) 

Ace 

ind; 

stkst 

(8) 

Ace 

ind; 

stkst 

(8) 

<;'  Ace 
ind; 

stkst. 
(8) 

Ace 
resp 

Ace 
resp 

PDU; 

popst 

-_  .. 

Pab 
ind 

"     lab 
ind 
(1) 

lab 
ind 
(1) 

lab 
ind 
(1) 

lab 
ind 
(1) 

lab 
ind 

(D 

lab 
ind 

lab 
ind 
(1) 

lab 
ind 
(1) 

lab 
req 

Aab 
req 
(1) 

Aab 
req 
(I) 

Aab 
req 

or 

Aab 
req 
(1) 

Aab 
req 
(1) 

Aab 
req 
(1) 

Aab 
req 
(1) 

Aab 
req 
(1) 

Irel 
req 

Arel 
req 
(9) 

Arel 
conf 

Irel 

conf 

(1) 

Event 
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In't! 
PDU 


Init 

resp 

(ACCE.: 


•.  Init 
resp 

(rjeje:  r 


Srcii 
PDU 


Srci: 

res;  i 


Prsnt 
PDU- 


Prsn; 
resr- 


Dlte 
PDU 


Dlu: 
res;; 


Rsc 
rec 


ft 

i 


m- 
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Table  23 
State  Table  for  Target  Systems 


a»j.» 


State 


Event 


Init 
PDU 


Closed 


Init 
ind 
(2) 


Init 
recvd 

2 


Open 


Search       Prsnt       Delete      Rsctrl       Acctrl      Rlease 
recvd         sent       ..  sent         recvd 
6  7  8  9 


recvd 
4 


recvd 
5 


[nit 

resp 

(ACCEPT) 

Init 

resp 

PDU(  +  ) 

(3) 

Init 

resp 

(REJECT) 

Init 

resp 

PDU(-) 

(I) 

Srch 
PDU 


Srch 
ind 
(4) 


Srch 
resp 


Srch 

resp 

PDU 

(3) 


Prsnt 
PDU 


Prsnt 
ind 
(5) 


Prsnt 
resp 


Prsnt 
resp 

PDU 
(3) 


Dlte 
PDU 


Dlte 
ind 
(6) 


Dlte 
resp 

Dlte 

resp 

PDU 

(3) 

Rsc 
req 

Rsc 

PDU; 

stkst 

(7) 

Rsc 

PDU; 

stkst 

(7) 

Rsc 

PDU; 

stkst 

(7) 

Rsc 

PDU; 

stkst 

(7) 

fw 


3&MM0 
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Tabic  23 
Continued 


State 

Closed 

Ink 

Open 

Search 

Prsnt 

Delete 

Rsctrl 

Acctrl 

Rlease 

recvd 

recvd 

recvd 

recvd 

sent 

sent 

recvd 

1 

2 

3 

4 

5 

6 

7 

8 

9 

Event 

.: 

Rsc 

Rsc 

rcsp 

conf; 

PDU 

popsl 

Ace 

Ace 

Ace 

Ace 

Ace 

PDU; 

PDU; 

PDU; 

PDU; 

req 

stkst 
(8) 

stkst 
(8) 

stkst 
(8) 

stkst 
(8) 

Ace 

Ace 

resp 

conf; 

PDU 

popst 

lab 

lab 

lab 

lab 

lab 

lab 

lab 

lab 

Pab 

ind 

ind 

ind 

ind 

ind 

ind 

ind 

ind 

Ind 

(1) 

(I) 

(1) 

0) 

(I) 

(1) 

(1) 

(1) 

Aab 

Aab 

Aab 

Aab 

Aab 

Aab 

Aab 

Aab 

lab 

req 

req 

req 

req 

req 

req 

req 

req 

req 

(1) 

0) 

(1) 

(I) 

'.     (1) 

(1) 

(I) 

(1) 

Irel 

Arel 

ind 

v. 

ind 

(9) 

r. 

Arel 

Irel 

resp 

resp 

(1) 

43  R-.:,: 
Option-  .  ,:.-. . ; 

4.4   Co:r   !•:.-..- 

comply  •• :  '    ' ; 
4.4.1  \i-i:;;  -,. 

-\    ....  ; 


4.4.2  !> 


•i  '• 


'4.43  fii.-.!:rv. 
l.-Thefci'.oO," 


2.  If  the  sy>:.-.-.' 
state  whciiu'r  :'•■■. 


I.)  ;;, 
■,■)  y 


3.  [fthev.M-- 
whether  ('.:•.•  • 
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43  Rules  for  Extensibility.  Unknown  data  cl—    and  unknown  options  within  the 
Options  data  element,  will  be  ignored  on  recetved  Init  APDUs. 

4.4  Conformance.  A  system  claiming  to  i^t  the  procedures  in  this  standard  shah 
comply  with  the  requirements  in  sections  4.4.1,  4.4.2,  and  4.4.3. 


4.4.1  Static  Requirements.  The  system  shall: 


^  act  in  the  role  of  an  origin  (by  sending  ■  Init,  Search,  and  Present 
}  APDU   and  receiving  Init-Response,  Search-Response  and  Present- 
Response  APDUs),  or  target  (by  responding  properly  to  Init,  Search, 
and  Present  APDUs  with  appropriate  Init-Response,  Search-Re- 
sponse and  Present-Response  APDUs),  or  both;  and, 

b)  support  the  syntax  in  section  4. 1;  and 

c)  support  the  Type- 1  Query. 


4.4.2  Dynamic  Rcquirements.-The  system'shall: 


a)  follow  all  the  procedures  specified  in  sections  4.1.1,  4.1.2.1,  4.2,  and 

b)  support  the  mapping  onto  the  Association  Control  Service  and  Pre- 
sentation  Service  (see  4.2.1);  and      '".      ,        ' 

c)  align  values  to  APDU  data  elements  according  to  the  procedures  .    • 
described  in  section  3. 

4.4 3  Statement  Requirements.  .  ;■.- 

1 .  The  following  shall-be  stated  by- the-  implementer.-. 

a)  whether  the  system  is  capable  of  acting  in  thefrole  of  origin, 

b)  whether  the  system  is  capable  of  acting  m  the  role  of  target, 

c)  that  the  system  supports  version  1  of  this  protocol.  • 

2.  If  the  system  claims  capability  of  acting  in  the  role  of  the  origin  the  implement  shall 
state  whether  the  system: 

a)  accepts  Access-Control  APDUs  and- sends  Access-Control-Response 

b)  aJcep^Resource-Control  APDUs  and  sends  Resource-Control-Re- 

sponse  APDUs,  ,Dnli' 

c^  sends  Delete  APDUs. and. accepts.Delete-Response  APDUs, 

d)  sends  Search  and  Present  APDUs  specifying  named  result  sets  other 

than  "default"  for  a  result  set  name. 

3.  If  the  system  claims  capability  of  acting  in  the  role  of  target,  the  implementer  shall  state 
whether  the  system: 

a)  sends  Access-Control  APDUs  and  accepts  Access-Control-Response 

b)  ^^Resource-Control  APDUs  and  accepts  Resource-Control-Re- 
sponse APDUs, 


*Zki 
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c)  accepts  Delete  APDUs  and  sends  Delete-Response  APDUs, 

d)  accepts  Search  and  Present  APDUs  specifying  named  result  sets.other 
than  "default"  as  a  result  set  name, 

e)  unilaterally  deletes  result  sets. 

4.  The  implementer  shall  state  to  what  extent  result  sets  may  be  specified  as  operands  in  a 
Type-1  query: 

a)  whether  named  result  sets  in  general,  or  only  the  default  result  set, 
may  be  used  as  an  operand  in  a  Type- 1  query, 

b)  whether  result  sets  may  be  specified  only  as  the  first  operand  in  a 
Type- 1  query,  or  that  they  may  be  specified  as  any  operand,     , 

c)  with  which  operators  (AND,  OR,  AND-NOT)  may  result  sets  be  used 
as  operands. 

5.  The  implementer  shall  state  to  what  extent  element  set  names  are  supported  in  Search 
and  Present  APDUs: 

a)  whether  the  parameter  Element-Set-Names  is  supported, 

b)  if  the  parameter  Element-Set-Names  is  supported,  whether  database 
names  corresponding  to  element  set  names  may  be  specified,  or  only  a 
single  element  set  name  and  no  corresponding  database  name  may  be 
specified. 

6.  The. implementer  shall. state  the  maximum  number  of  database  names,  that  mayr-be^.. 
specified  in  a  Search  APDU. 
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Appendix  A 
A  Transfer  Syntax  for  the  Protocol  Data  Units        , 

data  units. 

^r,ion.  Thus  the  several  format  is  a,  follows: 


A„     Health-—  -  ^^Sr^SSST  I  oo't 

items.  The  variable  portion  of  the  header ^  ^  of  Qrder  are  m 

SS^^S^^^-^"0^:      d  to  as  a 

ifics  the  size  (number  of  bytes)  of   ™nc-  bU  is  setj  in  which  case  it 
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its  first  byte  concatenated  with  the  lower  seven  bits  of  its  second  byte  (the  first,  or  leftmost 
byte,  is  higher  order).  Length  is  the  same  format  as  Tag. 
Examples: 

(1)  an  item  whose  Tag  is  3  and  whose  Value  occupies  two  bytes 
Bytes:     1  2  3  '     4 

000000 11     00000010    xxxxxxxx    xxxxxxxx 

(2)  an  item  whose  Tag  is  128  and  whose  Value  occupies  255  bytes 
Bytes:     I  2.3  4  5-259 

10000001    00000000     10000001     01 11 11 11     xxxxxxxx 

A.l.2.2  Tags.  Specific  fag  values  for  the  data  elements  used  in  the  PDUs  are  given  in 
Table  19  within  the  standard.  Note  that  all  data  elements  used  in  the  protocol  have  been 
assigned  Tag  values  within  the  standard;  however,  for  this  particular  transfer  syntax  not  all 
Tag  values  are  used.  For  example,  elements  in  the  fixed  portion  of  the  header  are  not  tagged, 
and  the  elements  Query  and  Database/Diagnostic-Records  occupy  the  user-information- 
part  of  the  PDUs  in  which  they  occur;  and  are  not  tagged. 
A.13  User  Information  Part.  The  user  information  part  occurs  in  the  following  APDUs: 

•  In  the  Ink  and  Init-Response  APDUs,  the  user  information  part  is  the 
element  User-Information-Held,  and  is  optional. 

•  In  the  Search  APDU,  the  user  information  part  is  the  element  Query, 
and  is  mandatory.  / 

•  In  the  Search- Response  APDU,  the  user  information  part  is  the  ele-  - 
ment  Database/Diagnostic-Records,  and  is  a  conditionally  occurring 

field. 

•  .In  the  Present-Response.  APDU.-the- user  information  part  is  the- ele- 

ment  Database/Diagnostic- Records,  and  is  a  conditionally  occurring 
field. 
All  other  APDUs  consist  entirely  of  theheader-length-indicator  and  the  header.- 

A.13.1  Record  Identification.  In  the  Search-Response  and  Present- Response  APDUs, 
•the  user-information-part  (if  present)  consists  of  the  item  Database/Diagnostic-Records, 
which  occurs  immediately  following  the  header  and  consists  of  one  or  more  structures^ the 

following  format: 

Table  Al 
Record  Identification 


Record  type 


Record  length 
Record 


byte  I,  binary  integer, 

The  following  record  types  zt.c  currently  defined: 

.    1  =  private  diagnostic  record,  for  example, 
as  specified  in  appendix  D 
2  =  database  record 
'additional  values  will  be  added  for  different 

categories  of  diagnostics. 

bytes  2  through  4;  binary  integer 
.  bytes  5,6  .... 

[f  Record  type  =  2,  this  field  is  either  of  two  forms 

— delimiter  database-record 

- — database-name  delimiter  database-record 

where  "database-name"  identifies  the  database  in 

which  the  record  resides,  and  "delimiter"  is  the 

ASCII  character  IF  (Hexadecimal). 
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Header: 
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A  2  APDU  Formats.  In  the  APDU  tables  below,  entries  for  "byte  positions"  are  meaningful 
only  for  items  in  the  fixed  portion  of  the  header.  The  entry  for  format,  for  variable  items, 
applies  only  to  the  "value"  portion  of  the  item. 

"ASCII"  refers  to  an  8-bit  ASCII  character  string,  and  when  it  occurs  in  the  tixcd 
portion  it  is  left-justified  and  blank  filled.  •■ 

"Bit-map"  refers  to  a  string  of  N  bits,  where  N  is  a  multiple  of  eight.  The  leftmost  bit  ot 
the  leftmost  byte  is  bit  I,  there  are  no  trailing  bytes  of  zero,  and  undefined  bits  used  to  pad  a 
byte  must  be  set  to  zero. 


Table  A2 
Init  APDU 

BYTE 
POSITIONS 


ITEM 


Header-Length-Indicator 
Header: 
Fixed  portion: 

PDU-Type 
Variable  portion: 

Protocol-version 


Options 


Preferred-Message-Size 
Maximum-Record-Size 
ID-Authentication 
.  Implementation-ID 
Implementation-Name 
Implementation- Version 
Reference-ID 
User  information  part: 

User-Information-Field 


1-2 


FORMAT 


binary  integer 


binary  integer   '    .' 

bit  map 

bit  1:1=  version  1 

bits  2-8:  0 
bit  map 

bit  1:  search 

bit  2:  present 

bit  3:  delete 

bit  4:  resource  control 

bit  5:  access  control 
.binary  integer    ■ 
binary  integer 
ANY 
ASCII 
ASCII 
ASCII 
ANY.     •  '• 

ANY 


m 


mz 
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ITEM 

Header-Length-Indicator 

Header. 
Fixed  portion: 

PDU-Type 

Result 
Variable  portion: 

Protocol-version 

Options 

Preferred-Message-Size 
Maximum-Record-Size 
Implementation-ID 
Implementation-Name 
Implementation- Version 
Reference-ID 
User  information  part 

User-Information-Field 


Tabic  A3      . 
Init-Rcsponse  APDU 
BYTE 
POSITIONS 


ITEM 

Header-Length-Indicator 

Header: 
Fixed  portion: 
PDU-fype 

Small-Set-Upper-Bound 
Large-Set-Lower-Bound 
Medium-Set-Present-Number 
Replace-Indicator 
Variable  portion: 
Result-Set-Name  . 
Database-Names 
Query-Type 
Element-Set-Names 
Reference-ID 
User  information  part: 
Query 


Table  A4 
Search  APD.U  • 
BYTE 
POSITIONS 


3 

4-6- 

7-9 

10-12 

13 


FORMAT 

binary  integer 


binary  integer 
binary  integer 

(see  Protocol- Version, 

Table  A2) 

(see  Options, 

Table  A2) 

binary  integer 

binary  integer 

ASCII 

ASCII 

ASCII 

ANY 

ANY 


FORMAT 


binary  integer 


binary  integer 
.  binary  integer 
binary  integer 
binary  integer 
binary  integer  '^-- 

ASCII 

ASCIl'(see  note  1) 
ASCII 

ASCII  (see  note  2) 
•  ANY 

(see  appendix  B) 


ITEM 


Note  (1):  If  more  than  one  database  name  is  specified  then  the  second 

the  ASCII  delimiter,  IF  (hexadecimal).  ..  . 

Note  (2)"  The  parameter  Element-Set-Names  is  one  of  the  following: 
(a)  delimiter  IF  (hexiadccimal)  +  a  single  element  set  name, 
b)  database  name  +  delimiter  IF  (hexiadecimal)  +  element 
(c)  more  than  one  occurrence  of  (b)  with  the  second  through 
the  delimiter  IE  (hexadecimal). 


through  the  last  is  preceded  by 


set  name,  or 

the  last  occurrence  preceded  by 
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Header: 
Fixed  r":,;:- 
PDU-7,; , 
Scare  *-:*-. 
Resn'-i-C  ■ 
Nuc.'-rr"- 

Variable  p" 
Resr.l'.-S.': 
Fk;z--~: 
Refc-;.-:- 
User  infer:..-'. 
Dat-'-r: 


nr- 


He?/:"-: 
Header.    . 
Fixed  p,":.;, 
PDU-?;. 

Nurvc-: 

Res':V:: 

VariaV..-  r  • 

Resi.M:- 

Ele;v  •.- 


Refr^:c 
User  infer  .V:.- 


ITEM 


Header: 

Fixed  ;: 
PDi  •' 
Nu- 
Rcsu 

Varia'r ' 
Rc<:. 
Elc- 

Rcfc- 
Uscr  inf.- 
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ITEM 


Tabic  A5 
Search-Response  APDU 
BYTE 
POSITIONS 


Header-Length-Indicator 

Header: 
Fixed  portion: 

PDU-Type 

Search-Status 

Result-Count 

Number-of-Records-Returned 

Next-Result-Set-Position 
Variable  portion: 

Result-Set-Status 

Present-Status 

Reference-ID 
User  information  part: 

Database/Diagnostic-Records 


1-2 


3     • 
4 

5-7 

8-10 

11-13 


FORMAT 


binary  integer 


binary  integer 
binary  integer 
binary  integer 
binary  integer 
binary  integer 

binary  integer 
binary  integer 
ANY 


(see  section  A.  1.3.1) 


uraf 


ITEM 


Header-Length-Indicator 
Header: 
Fixed  portion: 
PDU-Type 
Number-of-Records-Requested 

Result-Set-Start-Position 
Variable  portion: 
Result-Set-ID 
Element-Set-Names 

-    •  Reference-ID 
User  information  part:  (none) 


Table  A6 
Present  APDU 
BYTE 
POSITIONS 


1-2 


3 

4-6 

7-9 


ITEM 


Table  A7 
Present-Response  APDU 
BYTE 
POSITIONS 


Header-Length-Indicator 
Header. 
Fixed  portion: 

PDU-Type 

Number-of-Records-Requested 

Result-Set-Start-Position 
Variable  portion: 

Result-Set-ID 

Element-Set-Names 

Reference-ID 
User  information-  part:  (none) 


1-2 


3 

4-6 

7-9 


mmm 
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FORMAT 


binary  integer 


binary  integer 
binary  integer 
binary  integer 

ASCII 

ASCII.  See  note  (2)  of 

Table  A4 

ANY 


FORMAT 


binary  integer 


binary  integer 
binary  integer 
binary  integer 

ASCII 

ASCII.  See  note  (2)  of 

Table  A4 

ANY 
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Tabic  A8 

Delete  APDU 

BYTE 

ITEM 

POSITIONS 

FORMAT 

Header-Lcngth-Indicator 

1-2 

binacy  integer 

Hcaden 

Fixed  portion: 
PDU-Type 
Delete-Operation 

3 

4 

binary  integer 
binary  integer 

Variable  portion: 

ASCII 

Result-Set-ID 

ANY 

Reference-ID 

User  information  part  (none) 

Table  A9 

Delete-Response  APDU 

BYTE 

ITEM 

POSITIONS 

FORMAT 

Header-Length-Indicator 

1-2 

binary  integer 

Header: 

Fixed  portion: 
PDU-Type 
Delele-Status 

3 

4 

binary  integer 
binary  integer 

Variable  portion: 

/ 

ASCII 

binary  integer 
(see  note  below) 
ASCII 
,    ANY. 

Result-Set-ID 
Number-Not-Deleted 
Bulk-Statuses 
Delete-MSG 
Reference-ID  •'• 

•;' 

-    ■ 

User  information  part;  (none) 

Note-  The  parameter  Bulk-Statuses  is  one  of  the  following: 

(a)  Result-Set-ID  +  delimiter  1 F  (hexidecimal)  +  status,  or 
1 '  •  '       (b)  more  than  one  occurrence  of  (a)  with  the  second  through  the  last  occurrence  preceded  by 
the  delimiter  IE  (hexadecimal).  '  ■'  •''■.'.• 


Table  A10 

Xccess^ConffolTkPDU' 

BYTE 
POSITIONS 

., 

ITEM 

■FORMAT 

Header-Length-Indicator 
Header: 
Fixed  portion: 

PDU-Type      ■ 
Variable  portion: 
Security-Challenge 
Reference-ID 
User  information  part:  (none) 

1-2 
3 

binary  integer 

binary  integer 

ANY 
ANY 
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ITEM 


■  'Head---:-  •' 

Header; 

Fixed  p-".!' : 

PDL'->-:" 

Variable  -.m;  • 

Sccur'.;;.  f-  , 

Refc-;r;.v-:'- 

User  infcaii!-. 


ITEr-; 

Head::-!  :;■ 
Headen 
Fixed  pr.rli-r-!:] 
'  .'PDU-Tvp: 

Suspcr:iJ,-;d-r 
Variable  perl' 

Rescj:?.1-;'. 

PartiiO-R-.-: 

Refercr..Y-:: 
User  inforr.u'.ir." 


ITEM 


Header*  .;.-/• 
Headen 
Fixed  pnni.'T 
PDU-1-:- 

C6'ritiT.-.r"-P..: 

Variable  ;.'•■; i' .«. 
Resui1-^  ''.•"•  .:■ 
Refer::;ico-:i> 
User  infor;1. ■':!:■•"  :• 


!'i'iy;.:y/;-  .-*  •; 


0*"<?iiC'i-f< 
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ITEM 

Header-Lcngth-Indicator 

Header. 

Fixed  portion: 

PDU-Type 

Variable  portion: 
Security-Challenge-Response 

Reference-ID 
User  information  part:  (none) 


Tabic  All 
Acccss-Conlrol-Rcsponsc  APDU 
BYTE 
POSITIONS 


ITEM 


Header-Length-Indicator 

Header. 
Fixed  portion: 

PDU-Type 

Suspended-Rag 
Variable  portion: 

Resource-Report 

Partial-Results-Available 

Reference-ID 
User  information  part:  (none) 


Table  A12 
Resource-Control  APDU 
BYTE 
POSITIONS 


ITEM 


Header-Length-Indicator 

Header: 

Fixed  portion: 
PDU-Type 
Continue-Flag 
Variable  portion: 
Result-Set-Wanted 
Reference-ID 
User  information  part:  (none) 


Table  A13 
Resource-Control-Response  APDU 

BYTE 
POSITIONS 

1-2 


FORMAT 


binary  integer 


binary  integer 

ANY 
ANY 


FORMAT 


binary  integer 


binary  integer 
binary  integer 

ANY 

binary  integer 

ANY 


FORMAT 

binary  integer 


binary  integer 
binary  integer 

binary  integer 
ANY 
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Appendix  B 
A  Transfer  Syntax  for  the  Type-1  Query 

This  appendix  is  not  part  of  the  standard  but  is  included  for  information  only. 
This  appendix  specifies  a  default  transfer  syntax  for  the  Typc-1  query  as  referenced  in 
Table  A4.  The  Type-1  query  is  encoded  as  a  set  of  variable  length  items. 


ITEM 

Attribute-List 
Term 

Result-Set-ID 
Operator 


FORMAT 

ASCII  (see  tables  in  appendix  C) 

ANY 

ASCII 

ASCII: 

a  =  AND 

o  =  OR 

n  =  AND-NOT 
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HLVW,*; 


mmmm 


Vi.lt 


IIP 


This  ar  ;:.:. 
Theai'.-,':.. - 

CI  "AttHferT  ";;•"_ 
Each  r  ':-". "'" 


.  -.  ♦  '■>'.> ' 


C.2  Attribs:?^,;. 

USE  Value C^:- :-'■-. 
VALUE'/.,.  -,:X/': 
ISBN      >  <?■■<$&■''/ 

corporat;:-:;^' 

ISSN     •"•'••.  \*&£.:'i: 

personal-n^;;" 
subject,  En- 
title .x.;-;.  ■. 

GEOGRAFiiiq^:'.:  •• 

AUTHbR/7iT!'%  ^ 
CODEN      ■■%*:;■.■:■ 
SUBJECTSlili-p^ 
SERIES  TTTw".  f 
MICROFOr.VM-%.' 
PLACE-OFn.r:?'  ■'■ 
NUC-CODG.  .%■' 
LANGUAGE   ,.>.r>j 

combination'.-?:?" 

system-con?-^  > 

DATE  •  .  tef:'.:. 
LC-CONTR0!/:/v"v. 
MUSIC-PUr'S-.-- 
GOVERNMF.Njr  - 

SUBJECTCl.A-/.;; . 
RECORD-"n?i;,|>rr. 

POSITION  \fc$'j. 
VALUE  fJ&l 
ETRSTIN-Fi!:!%C' 
nRST-IN-S'J:';fL':-r 
FIRSTIN-$a-^'?> .'-" 

firstin-kcp;  ";>••.- 
any  posit;":,;J" 

TRUNCATI':N':;"-;v- 
VALUE  -'-I   \ 

no-trunc  ••::•.'."•"■" 

R1GHT-TRU'-''!-. 
PROCESS-M  ■•'!;    :- 
SEARCH  AP.'  '. ':'" 


lis 


Appendix  C 

An  Exomple  of  Am**..  «-'  «»  «"*  ,h°  T^e-'  QUOry, 

,  «r  ih«-  standard  but  is  included  for  information  only. 

•  use 

•  relation 
-  position 
«  structure 

.    truncation 
■>    completeness. 


C.2  Attribute  Values 

USE  Value  Codes 

VALUE 

ISBN 
CORPORATE-NAME 

ISSN 
PERSONAL-NAME 

SUBJECT 

TITLE 

GEOGRAPHIC  NAME 

AUTHOR/TITLE  Value  Codes 

CODEN 
SUBJECT-SUBDIVISION 

SERIES  TITLE 
•    MICROFORM-GENERATION 
PLACE-OF-PUBLICATION 
NUC-CODE 

LANGUAGE  rl„M,,Q 

COMBINATION-OF-USE-VALUES 

SYSTEM-CONTROLNUMBER 

DATE 
LC-CONTROLNUMBER 

SUBJECT-CLASSIFICATION 
RECORD-TYPE 

POSITION  Value  Codes 

VALUE 

FIRST-IN-FIELD 

FIRST-IN-SUBFIELD 

FIRST-IN-Sa-SUBFIELD 

RRST-IN-NOT-$a-SUBFIELD 

ANY  POSITION-IN-FIELD 

TRUNCATION  Value  Codes 

VALUE 

NO-TRUNCATION 
RIGHT-TRUNCATION 
PROCESS-#-INCLUDED  IN 
SEARCH  ARGUMENT 


CODE 

ub 
uc 
us 
up 

uj 
ut 

ug 

ua 

ud 

ue 

uf 

uh 

ui 

uk 

ul 

um 

un 

uo 

ur 

uu 

uv 

uw 

uy 

CODE 

pf 
ps 
pa 
Pf   r 

py 


CODE 

tn 
tr 

ti 


RELATION  Value  Codes 

VALUE 

EQUAL 

GREATER-THAN 

GREATER-THAN-OR-EQUAL 

LESS-THAN 
LESS-THAN-OR-EQUAL 

NOT-EQUAL 


CODE 

re 

rg    • 

ro 

rl 

rp 

rn 


STRUCTURE  Value  Codes 
VALUE 
PHRASE 
WORD 
KEY 
■  WORD-LIST 

COMPLETENESS  Value  Codes 

VALUE 
[NCOMPLETE-SUBFIELD 

COMPLETE-SUBFIELD 
COMPLETE-FIELD 


CODE 

sp 
sw 
sk 
si 


CODE 

ci 
cs 


cf 
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life 

SllP 

•  0rV  ■ 
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Appendix  D 
An  Example  of  a  Diagnostic  Record  Format 

This  appendix  is  not  part  of  the  standard  but  is  included  for  information  only.  However, 
implementers  should  be  aware  that  it  is  necessary  to  define  the  format  and  content  of  some 
set  of  diagnostic  records  as  part  of  the  implementation  for  any  system  acting  in  the  role  of 
target,  and  this  definition  should  be  part  of  the  implementation's  documentation. 

DX  Diagnostic  Record  Format.  The  following  format  for  diagnostic  records  was  developed 
for'a  specific  interchange  implementation.  It  is  presented  here  as  one  example  of  such  a 
format.  All  data  is  ASCII. 

VALUE 

n  +  3.  n  =  length  of  ADDINFO,  and  may  be  zero. 
Error  condition,  summarized  in  D.2. 
Additional  information  concerning  the  error 
condition.  Optional  in  all  cases.  See  note  [1]. 
End  of  record  mark  (ID  hex),  n  =  length  of 
ADDINFO  and  may  be  zero. 


NAME 

BYTES 

LENGTH 

1,2 

DIAG 

3,4 

ADDINFO 

5  to5  +  n-l 

if  present 

EOF 

n  +  5 

D.2  Diagnostics 

VALUE 

SI 

S2 

S3  * 

S5 

S6 

S7 

S8 

S9 

SA 

SB 

SC 

SD 

SF  ■ 

SG 

SH 

SI  ..      

SJ 
SK 
SL 
SM  ■ 

SN 
SO 
SP 
SQ 
SR 

SS 
ST 
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MEANING 

Permanent  system  error 

Temporary  system  error 

Unsupported  search 

Terms  only  exclusion  (stop)  words 

Too  many  argument  words 

Too  many  boolean  operators 

Too  many  truncated  words 

Too  many  "incomplete  subfietds 

Truncated  words  too  short 

Invalid  format  for  record  number  (search  term) 

Too  many  characters  in  search  statement 

Too  many  records  retrieved 

Present  request  out-of-range  (see  note  [2]) 

System  error  in  presenting  records 

Record  not  authorized  to  be  sent  intersystem 

Record  exceeds  Rreferred-message-size 

Record  exceeds  Maximum-record-size 

Result  set  not  supported  as  a  search-term 

OnlysiV]£/e-result:setas  search  term  supported 

Only  AND'mg  of  a  single  result  set  as  search 

Term  supported  .       _.  . 

Result  set  exists  and  replace  indicator  off 

Result  set  naming  not  supported 

Combination  of  specified  databases  not  supported 

Element  set  names  not  supported 

Specified  element  set  name  not  valid  for 

specified  database 

Only  a  single  element  set  name  supported 

Result  set  no  longer  exists— unilaterally 

•  deleted  by  target 


TYPE 
(1) 
(f) 
(2) 
(2) 
(2)  ' 
(2) 
(2) 
(2) 
(2) 
(2) 
(2) 
"J  .(2) 
s'  (3)  : 
(4) 
(4) 
(4) 
(4) 
(2) 
.      (2) 

(2) 
(2) 
(2) 
(2) 
(1) 

(1) 
(1) 

(1) 


su 

Sv 

SW 

sx 

sy;  • 

-■•*!'  ■ 

SZ:' 

■!')>'.•.••' •.' 

Tl 

T2 

T3 

T4 

Types:  (:•:.;■. ; 

•  sp'ir 

•-.  ('- ' ■■■:• ' 

(•:!.•>. 

Notes: 

(1H  The  At.--,;.. 

k-ator.  >£•;';.:: 

sd,  a:-:::'-. 

.  con's::* '.'.    " 

'sup'r.-.-.  -i 

[2]  DiaBr.".:::  =  ! 

when  r::;!'' 
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Result  scl  is  in  use 

One  of  the  specified  databases  ts  locked 
Terminated  by  negativee  continue  response 
SDCcified  result  set  does  not  exist 
Sources  exhausted-no  results  ava.lable 
Resources  exhausted-unpredictable  partial 

^rd  exhausted-valid  subset  of  results 

available 

Access-Control  failure 

Purity  challenge  required  but  could  not  be 

Issued— request  terminated 

Security  challenge  required  but  could  not  be 

Issued— record  not  included  „ 

TVPES:  (I^^^ESSSErSffi^" 

(2)  May  occur  only  when  searcn  swuj       „f  •,..„" 

g   May  occur  only  ^-^^raVataS^ord. 
(4)  May  occur  only  as  a  surrogate  mi* ^^ 


SU 

Sv 

SW 

SX 

SY 

SZ 

Tl 

T2 
T3 

T4 


(1) 
(1) 
(0 
(0 
(2) 

(2) 

(2) 
(1) 

(0 
(4) 


Notes: 


iiv: 


Hi 


IIP 
H 


mm 


»*?> 


W*-v'-. 


fas- 


sg®^; 


Pife 


S*^>.i'i£i>V 


^s;r"  • 


gggggg 


US 


8ii&8l: 


6.  How  do  you  rate  this  standard?  (circle  one) 


t  2  3 

Poor     Marginal      Fair 


4  5 

Satisfactory     Good 


6  7 

Abovo  Average 


10 


Very  Good      Excellent     Outstanding 


7.  How  do  you  rate  your  experience  and  results  in  using  this  standard?  (circle  one) 


1  2  3 

Poor     Marginal     Fair 


4  S 

Satisfactory     Good 


6  7 

Above  Average 


8  9  10 

Very  Good     Excellent     Outstanding 


8.  How  could  this  standard  be  improved? 


9.  Would  you  be  interested  in  working  on  revisions  to  this  standard  or  on  other  stan- 
dards in  the  same  area?  

□  Yes  U   No 

10.  Other  comments  (You  are  welcome  to  attach  additional  material): 


11.  Form  completed  by:      Name 

Title  _ 


Organization. 
Address. 


Telephone  Number  ( 
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